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sztráda? AC? DC? 


A sajtó, a politika tele van informatikáról szóló hírekkel. A köznép ettől azt 
hiszi: lemarad, ha kimarad. Ezt a tévhitet erősíti a politika a különböző 
számítógépvásárlási akciókkal. Lassan boldog-boldogtalan rendelkezni fog 
otthoni számítógéppel és Internetkapcsolattal. De kérdem én: minek? Egyfe- 
lől még mind a mai napig nem tudjuk, mire is lesz jó az Internet hétközna- 
pi életünkben (telefonon pizzát rendelni bájosabban, hagyományos könyvtár- 
ban olvasni elmélyültebben lehet stb.), sőt, azt sem tudjuk, milyen eszköz- 
zel fogjuk csinálni azt a valamit, amiről fogalmunk sincs, hogy mi. 

Az utca embere tehát vesz egy számítógépet, melyet maximum játszásra hasz- 
nál, majd két év múlva kidobja (vennél-e bármilyen más játékszert súlyos száz- 
ezrekért?) . Ennél nagyobb , károkról" is beszélnek: nemrég olvastam egy felmé- 
rést arról, hogy az amerikai nyomtatott sajtó neves lapjai hogyan vészelték át a dotkom-őrületet. Az új- 
ságok háromféleképpen közelítették meg a problémát: vagy maguk is beszálltak az Internetre menetelbe 
(vagy úgy, hogy a nyomtatott lapot — némi késleltetéssel - egy az egyben kirakták (1. változat), vagy úgy, 
hogy tartalmi módosításokkal webre szabták(2. változat) ) , vagy bele sem kezdtek a , felzárkózásba" (3. vál- 
tozat). Tippeljenek, melyik stratégia hozta a legkisebb veszteséget, mind dollárban, mind előfizetői lét- 
számban? Hát bizony a harmadik. Ennek rengeteg oka van, mindenki tudna mondani legalább hármat. 
Wagy wegyük a webkereskedelmet: gyakorlatilag ugyanakkora személyzet és raktár kell hozzá, mint a ha- 
gyományos kereskedéshez. Egy látványos különbség van: az áruháznak nem kell csillognia-villognia, mert 
senki sem tér be hús-vér mivoltában. Ezt a költésmegtakarítást azonban beleölhetjük a magasan képzett 
informatikus szakembergárdába: a kirakat, és a polcok ,átrakodásához" immár nem segédmunkásokat, ha- 
nem programozásban jártas szakembereket kell igénybevenni, a biztonsági őr sem lehet akárki, mert az 
áruházi tolvaj sem hagyományos: a hackerek ellen okos ember kell! 


Az 1900-as évek elején már volt villanyvilágítás. A váltóáram , feltalálása" előtt nem lehetett tetszőleges 
távolságra tenni a fogyasztókat a telepektől, mert a kilométerek ,megzabálták az áramot". Ahol villany- 
világítás volt, ott a közelben áramtelepnek is lennie kellett. Izzó tömeggyártás alatt havi háromezer da- 
rabot értettek. Amikor felmerült az igény, hogy a közvilágítást is villannyal oldják meg, az akkori korlá- 
tok mellett nyilvánvaló volt, hogy a sugárutakat és körutakat nem lehet füzérszerűen kivilágítani, mert 
egyrész a világ összes villanykörtéje sem lenne elég, másrészt párszáz méterenként telepeket kellett vol- 
na letenni. És jött az ötlet: hatalmas villanykörtéket kell készíteni, és fellógatni egy-egy kerület fölé! 


Száz év elteltével sem tudunk elszakadni a fenti a sémától: az új technológiát a jelen korlátai men- 
tén próbáljuk különféle célokra használni. Az utókor röhögni fog rajtunk, ez nem vitás. 


Váltóáram 

Anno a váltóáram pillanatok alatt lesöpörte a föld színéről az egyenáramú energiaszolgáltatást és fel- 
használást. (A zseblámpa, a walkman, a digitális fényképezőgépek visszamaradott őskövületek csupán, 
hisz teleppel működnek. :-) 


Nem vagyok biztos benne, de erősen érzem, hogy a .NET keretrendszer megjelenése hamaro- 
san rendet vág a hagyományos webalkalmazások sorában. 


Kell persze alkotó elme is a technológiához. , A webszolgáltatások segítségével akármi megvalósítha- 
tó!" - mondja a marketing. Azt azonban nem mondja meg, mi az az akármi. Bármi és kész. 
Sajnos én sem látom a jövőt, így nem tudnám megmondani, mit takar a bármi. De egy biztos: lassan 
megszületnek azok a webalkalmazások, amelyek már nem a jelen üzleti folyamatainak webesített vál- 
tozatai, hanem ízig-vérig Internetesek: háló nélkül még csak értelmezni sem lehet majd őket. 
Felhasználói felületként pedig akármi szóbajöhet. Akármi alatt olyan eszközöket értek, amit még ki 
sem találtak. 
Valószínűleg most sem Magyarország áll majd a fejlődés élén (a tízmillió Nobel-díjas országa!) : figyel- 
jünk a világra! A .NET Akadémia cikksorozat ehhez próbál hozzájárulni. 
Fóti Marcell 
marcellfonetAcademia.net 
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Exchange 2000 


Méltatlanul elfeledett termékre térünk vissza: az Exchange Serverre. 

Nem a felhasználók feledték el, hanem mi nem törődtünk vele ezidáig megfelelően. 
Most útjára indítjuk Exchange Server sorozatunkat, mely a telepítéstől kezdve 
végigvezet a termék használatának rejtelmein. 





General [/dccess ] Messages ] Delvery [/LDAP Rowing ] Securty ] 


ÉS DetattöMTP Velvet Sérvet 


Hame: Data SMTP Vitus Server 
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T Conígun  Configure multiple idendites for this viual servet. 
Cluster a gyakorlatban (V. rész) Les eze 
Ezúttal is alapozómunkát végzünk, folytatjuk az ismerkedést az erőforrástípusokkal. Nem TT Enat fopAdászz ea 
ígérhetek könnyű olvasmányt: minden típusnak megvan a maga bogara, és nem árt ezekkel TÉTeBSE 
tisztában lenni, mielőtt használni akarjuk őket. A Microsoft hozzászoktatott minket a va- 
rázslók használatához, most viszont bőven akad majd dolgunk , kézzel" is. 
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Set the policy for the oplionz valable to uters during the cbent nitalaton 
vözard, 


(IV. rész) 


Automata Selugy [ €istom Sep 1 
Kt Eszi "] Az elmúlt négy cikkben a RIS-t elég jól megismerhettük minden oldalról, a mostani cikk 
e bej ] 6 Derg ] ráadás. Nem létfontosságú, de azért hasznos dolgokról lesz szó. A cikk első felében a 


telepítő elindításához használt varázsló, a CIW képernyőiről lesz szó - ismerkedünk 
TERE; fize velük, majd megpróbáljuk átformálni őket. A másodikban megnézzük több telephelyes kör- 
C Dontese ]/ Ciösnese nyezetben a RIS kiszolgálók elhelyezését, a szinkronizálás lehetőségeit. 
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Függőségi viszonyok s 


(! ) AtI t B 0 At least one service or driver failed during system startup. Use Event Viewer to 
, FESZ east one service - 


examine the event log for details. 
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Open Shortest Path First 


RRAS sorozatunkban utoljára a RIP útválasztási protokollal foglalkoztunk, és 
megállapítottuk hiányosságait: lassú konvergenciáját, hurokérzékenységét, 15 
hopos korlátját - egyszóval butaságát. A RIP ismert gyengeségeit nem a követ- 
kező verzió kivárásával kell orvosolni, hanem - ha hálózatunk méretével, bonyo- 
lultságával a RIP nem tud megbirkózni - áttérhetünk egy sokkal fejlettebb útvá- 
lasztási protokoll, az OSPF használatára 
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"s eze! zzz A Windows 2000 és a 


General] StattofAuthorly(S0AJ — ] Name Server 


Bis ati dinamikus DNS 











e SE nt Mindenki tudja, hogy a Windows 2000 tartományok elsődleges névfeloldó 
Zone le name: szolgáltatásává (a WINS-et és egyéb NetBIOS varázslásokat végre leváltva) a DNS lé- 
[dorazhad———— pett elő. A Windows 2000 munkaállomások a DNS segítségével lépnek be a tarto- 
Állow dynamic updates? he z]  mányba, jelentkeznek be a hálózatba, veszik fel egymással a kapcsolatot. 








he: 
l Security ] 





e e 
Ki mivel p? 
Az életmentő LDAP 
Januárban indítottuk útjára ,Ki mivel 9" rovatunkat, melyben időről időre 
beszámolunk egy-egy kacifántos, esetleg rejtélyes , ügy" megoldásáról. 
Ez a rovat nyitott: ha valaki munkája során olyan kíntapasztalatra tesz szert, 
mellyel mások szenvedését enyhítheti, kérem írjon nekünk a cikktipp(onetacademia.net címre! 
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Mikor és miért felel az internetszolgáltató? 


A 2001. évi CVII. törvény legfontosabb előremutató rendelkezése a szolgáltatói felelősség 
szabályozása. A kérdés alapvetően természetesen az, hogy a hálóra felkerült tartalomért a szolgáltatást 
nyújtók mely csoportja, és milyen mértékű felelősséggel tartozik. 


ASP Suli 


Outlook Wap Acces 
Az elmúlt két hónapban megismerkedtünk a WML 
programozás alapjaival. Most itt az ideje, hogy 
valami maradandót alkossunk: cikkünkben az 
ús ka Exchange 2000 CDO ek eg éeak úeg Aoás 
megvalósítjuk az Outlook Web Access 
e N et akad emlila szuperkompakt változatát: 
ii, tész ez lesz az Outlook Wap Access. 
Az előző két részben megtekintettük az osztályok 
alapvető lakóit, megnéztük, hogyan kezeli a .NET 
a típusaink által igényelt memóriát. Most 
továbbhaladunk az objektumorientált jellemzők mentén, 
és megnézünk néhány fejlettebb típust, 
amelyek nagy segítséget jelentenek áttekinthető, 
könnyen bővíthető és karbantartható 
programok írásában. 





XMLgessünk 
Átjárás a relációs és az xml világ között 
Folytatjuk a relációs adatbázisok és az xml világ közötti átjárást. 


Tovább boncolgatjuk a DataSet osztály szolgáltatásait, és megszemlélünk egy valódi 
virtuózt, az XmIDataDocument objektumot. 
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Farkasokkal táncoló 
(V. rész) - Cluster a gyakorlatban 


Ezúttal is alapozómunkát végzünk, folytatjuk az ismerkedést az 

erőforrástípusokkal. Nem ígérhetek könnyű olvasmányt: minden típusnak 

megvan a maga bogara, és nem árt ezekkel tisztában lenni, mielőtt használni akarjuk 
őket. A Microsoft hozzászoktatott minket a varázslók használatához, 

most viszont bőven akad majd dolgunk , kézzel" is. 


Olyan infrastrukturális szolgáltatásokról szólunk, mint a DTC és 
az IIS, az SMTP, az NNTP, a WINS és a DHCP. 


A Distribution Transaction Coordinator 

Őszintén bevallom, nem tartozom a fejlesztők csapatába, ezért 
nem sok figyelmet szenteltem az MSDTC szolgáltatásnak, a fürt- 
szolgáltatással való ismerkedésem során pedig sosem gondoltam 
volna, hogy ezzel az erőforrással valaha találkozni fogok. Holott 
igen fontos dologról van szó. A Microsoft meglehetősen sok al- 
kalmazását készítette el úgy, hogy számít az MSDTC meglétére - 
talán ezért is került be a Windows 2000 operációs rendszerbe. 
Ilyen alkalmazás az SOL, a BizTalk, az Application Server, a 
Commerce Server, a Message Oueue Server és bizonyos esetekben 
az IIS is. Olyannyira fontos lehet ez, hogy például az MSDTC-t 
mindenképp az SOL előtt érdemes fürtösíteni. Akik tehát ilyen 
alkalmazásokat üzemeltetnek majd fürtkiszolgáló környezetben, 
azoknak érdemes megismerkedniük az MSDTC erőforrással. 

A Distributed Transaction Coordinator talán az egyik legfurább 
erőforrás. Két érdekes tulajdonsága is van. Minden leírás szerint 
(lásd a cikk végén a KB hivatkozásokat) egyetlen példány elég be- 
tőle fürtönként, vagyis úgy viselkedik, mint a guorum lemez vagy 
a többi clustercsoportbeli erőforrás. A 0294209 szerint a cluster- 
csoportban a helye, én azonban nem osztom ezt a véleményt, mert 
a saját tapasztalatom az, hogy az MSDTC jó pár más erőforrást is 
magával , ragad", ami nem kívánatos. A másik érdekes tulajdonsá- 
ga, szintén minden forrás szerint, hogy nem a szokásos módon és 
felületről lehet létrehozni. No, nézzük ezt a csodabogarat! 

"2 Először győződjünk meg róla, hogy az MSDTC mindkét állomá- 
son fut. (Az biztos, hogy létezik ilyen service, mert a Windows 
2000 nem is telepíthető e nélkül). 

Válasszuk ki azt a csoportot, ahol az erőforrást létre akarjuk 
hozni. Előfeltétel, hogy ebben a csoportban legyen egy le- 
mez, egy hálózati név és egy IP cím erőforrás. 

Hozzuk létre az MSDTC-t az erőforrás varázslóval. 

Tegyük függővé a hálózati névtől. 

Hagyjuk az MSDTC-t offline állapotban. 

Hozzunk létre a csoport fizikai lemezén egy dtclog könyvtárat. 
Az egyik állomás Winnttsystem32tdtclog könyvtárából má- 
soljuk át a fájlokat a közös meghajtón lévő mappába. 
Tegyük függővé attól a fizikai lemez erőforrástól, amely az 
előző könyvtárat tárolja. 

Ha minden rendben van, akkor futtassuk a comclust.exe prog- 
ramot parancssorból az első állomáson, majd a másodikon is. 
A comclust egy clb erőforrást is hozzáadna a clusterhez, de ez 
nem sikerül neki, a figyelmeztetését nem kell komolyan venni. 
A lényeg, hogy az MSDTC létrejött. (Lásd 1. ábra) 
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5 Az MSDTC erőforrást létrehoztuk. A COM4- -ra vonatkozó 
információkat figyelmen kívül hagyhatjuk. 


Miért van szükség erre a hókusz-pókuszra? Nos, tapasztalataim 
alapján azért, mert az erőforrás varázsló és az MSDTC nincs 
összecsiszolva. A varázsló nem mozgatja át a már meglévő 
logokat a közös lemezre. Kitalálták tehát a fejlesztők a comclust 
programot, amely képes egy teljes MSDTC erőforrást létrehozni 
a következő változásokkal: 

2 Létrehozza az erőforrást. 

8 Létrehoz egy közös lemezen egy könyvtárat a tranzakció 
logoknak. 

Átmásolja a regisztrációs adatbázis megfelelő részét a cluster 
hive alá. 

Csakhogy a comclust az első lehetséges csoportot választja ki, 
ahol van fizikai lemez, IP cím és hálózati név. Az első csoport 
általában a cluster erőforráscsoport, ide kerülne be az MSDTC, 
amely egyáltalán nem kívánatos. Ezért kell , rábeszélni" a segéd- 
programot, hogy a mi elképzeléseinket kövesse, és az általunk 
preferált csoportba kerüljön az MSDTC. 

Mindenképpen javaslom, hogy a sikeres létrehozás után teszteljük 
az át- és visszaköltözést. Az MSDTC-től függő újabb erőforrások te- 
lepítése után (SOL, Biztalk stb.) pedig újra végezzük el a tesztet. 
Előfordulhat persze, hogy a kiszolgálófürtöt úgy kaptuk meg, 
hogy a tranzakció koordinátor a cluster csoportban van. Ha sze- 
retnénk más csoportba áthelyezni, van rá mód, a 0243204 cikk- 
ben leírtak szerint. Mondanom sem kell, ahogy nem használha- 
tó az egyszerű erőforrás-varázsló a létrehozáskor, úgy nem lehet 
egy egérkattintással áthelyezni sem az MSDTC-t. 

Nehéz volt? Lehetett volna ennél sokkal bonyolultabb is a létre- 
hozás, akit érdekel a cikk végén talál némi irodalmat. Ha pedig 
valaki aggódna, hogy minden könyvtár-költöztetés problémát je- 
lent majd, azokat szeretném megnyugtatni: elég, ha továbbol- 
vassa a cikket, a DHCP és a WINS nem szenved ilyen gondoktól. 


S0NS: 3: 


Az Internet Information Server 

Most, hogy már minden csínját-bínját ismerjük az MS DTC létreho- 
zásának és életben tartásának, nekiugorhatunk az IIS-nek is. Azért 
kellett a tranzakció-koordinátorral kezdeni, mert a webhelyünk 
esetleg tranzakciókat használ. Ilyenkor az IIS erőforrást függővé 
kell tenni az MSDTC-től, egyébként - természetesen - nem. 
Ahogy azt korábban is tettük, győződjünk meg, hogy az IIS 
mindkét állomáson működik. Semmi nem említi ugyan, de cél- 
szerű ugyanazokat a szoftverkomponenseket telepíteni mindkét 
szerveren, rejtett hibákat lehet így elkerülni. 

A továbbiakban feltételezem, hogy már létezik egy erőforráscso- 
port, amelynek van legalább egy lemezerőforrása, egy IP címe 
és egy hálózati neve, továbbá, hogy ebben a csoportban defi- 
niáltuk az MSDTC erőforrást is. 

0 Hozzunk létre a lemezerőforráson egy könyvtárat, amely majd 
a publikálandó anyagainkat tartalmazza. Lehet ez például 
N: InetPublWWWRoot. Helyezzünk el a könyvtárban valami- 
lyen tartalmat, hogy később tesztelni tudjuk a működését. 
Hozzunk létre egy IP cím erőforrást. Ez lesz majd az IIS szer- 
verünk IP címe. Tegyük az IP címet függővé az MSDTC erő- 
forrástól. 

Az egyik állomáson, - célszerűen azon, amelyik a csoportunkat 
birtokolja - hozzunk létre az IIS MMC beépülő moduljával egy 
új webhelyet (Web Site). Az IP cím és az alapértelmezett könyv- 
tár legyenek azok, amelyekről az előző két pontban szó volt. 

A cluster administrator segítségével hozzunk létre az erőforrás- 
csoportunkban egy IIS erőforráspéldányt. A szokásos kérdé- 
seken túl csak arra kell válaszolnunk, hogy melyik Webhelyet 
akarjuk fürtözni, s hogy annak mi a típusa. 


b 


b 


b 
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5 Az erőforrásvarázsló utolsó kérdése az IIS erőforrás létre- 
hozásakor 


Ezzel az első állomáson végeztünk - de csak az elsőn! Rá kelle- 
ne venni a másik állomást, hogy az IIS konfigurációja ugyanaz 
legyen, mint elsőé. Másképp fogalmazva: a két állomás 
metabase adatbázisát szinkronizálni kell. IIS 4.0-tól létezik egy 
segédprogram, amely épp erre hivatott, iissync a neve. Haszná- 
latának az a feltétele, hogy az anonim felhasználókat megsze- 
mélyesítő felhasználói fiókok (IUSR kiszolgálónév, IWAM kiszol- 
gálónév) azonosak legyenek mindkét állomáson. Célszerű tehát 
létrehozni egy IUSR cluster és IVWAM. cluster felhasználót, majd 
hog on locally" felhasználói jogot adni nekik a fürt állomásai- 
ra vonatkozóan. Ezt az alábbi lépéseknek kell követnie: 
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windows / 


2 Az Internet Services Managerben ki kell válasz- 
tani a friss, fürtözött webhelyet, és a , Directory 
security" tulajdonságlapján módosítani kell a név- 
telen hozzáférések fiókját az új IUSR cluster névre. 

A Josystemdrive9o:Nnetpubtadminscripts könyvtárból le kell 
futtatni az alábbi parancsokat: 


Cscript adsutil.vbs SET W3SVC/WAMUserName 

4. domainVIUAM cluster 

Cscript adsutil.vbs SET W3SVC/WAMUserPass " jelszo" 

2 Végezetül kiadhatjuk a régen várt parancsot arról az állomás- 
ról, amelyik a helyes IIS beállításokat tartalmazza: 


iissync masikallomasneve 


Előfordulhat persze, hogy elsőre nem sikerül a szinkronizálás, 
ahogy azt az ábra is mutatja. 








5 Ez a szinkronizálás még nem sikerült... 


A sikertelenség senkit ne keserítsen el. A 0224801 cikk a hibakó- 
dokat és a lehetséges okokat fejti vissza. A fenti hiba oka való- 
színűleg az, hogy a két állomáson nem azonos javítócsomag van. 
Ha sikeresen lefutott az IISSYNC, akkor már csak azt kell tesz- 
telni, hogy az át- és visszaköltözés problémamentes-e, s máris 
készen vagyunk: előállt egy hibatűrő IIS szerver. 
Megkérdezheti a Kedves Olvasó, hogy vajon mi értelme van 
egyáltalán az IIS ilyetén konfigurálásának, hiszen van sokkal 
jobb módszer is nagy rendelkezésre állású webfarm létrehozásá- 
ra, mégpedig az NLBS. Nos, a válasz az, hogy a Kedves Olvasó- 
nak igaza van, amennyiben az IIS a , cél". Ám nem szabad elfe- 
lejteni, hogy az IIS maga lehet , eszköz" is, amelyet egy másik 
alkalmazás kíván használni. Ha egyenszilárdságot akarunk, és 
mindkettőt azonos szerveren helyezzük el, akkor ésszerű mind- 
kettőnek azonos rendelkezésre állást biztosítani. Ezért van ér- 
telme az IIS erőforrás létrehozásának. 


Az SMTP és az NNTP erőforrás 

Az Internet Information Serverhez hasonlóan fürtözhető az IIS- 

hez járó SMTP és NNTP szolgáltatás is, méghozzá az IIS-hez egé- 

szen hasonló módon. Ezeknél a szolgáltatásoknál csupán az a 

fontos, hogy a fürtökre feltett SMTP más porton , figyeljen", 

mint a virtuális szerveren definiált. A szolgáltatásokhoz előfel- 

tétel az IIS fürtösítése, vagyis mindaz, amit eddig leírtunk. Lás- 

suk, hogyan működik az SMTP fürt a gyakorlatban: 

-£ Győződjünk meg róla, hogy mindkét állomáson telepítve van 
az SMTP. (Ha az IIS-nél precízen dolgoztunk, akkor ez nem gond.) 

8 Győződjünk meg arról, hogy mindkét állomáson kézi indítású 
az SMTP szolgáltatás, és LocalSystem fiók alatt fut. 

8 Indítsuk el az adminisztrációs eszközök közül a Computer 
Managert, és az Internet Information Services modulban vá- 
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lasszuk ki az alapértelmezett SMTP virtuális szerver 
tulajdonságait. Az első lapon látható , Advanced..." 
gombra kattintva átállíthatjuk az állomás SMTP 
szerverének alapértelmezett portját. Erre azért van 
szükség, hogy a node képes legyen fogadni egy 
olyan virtuális SMTP kiszolgálót, amelyik majd a 25- 
ös, tehát a normál portot használja. 


Default SMTP virtual Server Properties K1Ei 


General ] Access ] Messages ] Defvey ] LDAP Routing ] Security ] 









Ez Default SMTP Virtual Server 


Name: Default SMTP Virtual Server 
IE addtess: (AN Unassigned) s] Advanced... 
 comecte DESEZEZT RT 7] 


Configun fi az a Ek ő 
ésöürós Configure multiple identities for this virtual server. 














Address: 
TT Enat [IP Address TCP Port 
A o NELESREZ] 25 















E Add... Edít.. Remove I 


FEST [dor] cmd [/ Her 


o A fürtkiszolgáló felkészítése nagy rendelkezésre állású 
SMTP kiszolgáló fogadására 





"0 Ezután - akárcsak az IIS esetében - hozzunk létre egy új vir- 
tuális SMTP kiszolgálót, amelyet majd fürtözni fogunk. 
Miután ezzel is végeztünk, a cluster administrator segítségé- 
vel létrehozhatjuk az SMTP erőforrást, amelyet függővé kell 
tenni az IIS IP címétől, magától az IIS erőforrástól, és a fi- 
zikai lemeztől, amely a mailroot könyvtárat tartalmazza. 

"0 Az utolsó előtti lépés az IISSYNC futtatása, valamint a másik 
node alapértelmezett SMTP virtuális szervere portjának átál- 
lítása. 

"0 Végezetül tesztelni kell, hogy az át- és visszaköltözés problé- 
mamentesen működik. 

Tekintve, hogy a NNTP szolgáltatás ikertestvére az SMTP-nek, 

nem válok felületessé, ha azt mondom: csak ugyanúgy, mint az 

SMTP protokollnál. 


A Windows Internet Name Service és a Dynamic Host 
Configuration Protocol erőforrások 

A cikk elején már említettem, hogy a WINS és DHCP erőforrások 
korántsem olyan problémásak, mint például az MSDTC. Valósá- 
gos felüdülés a telepítés az előzőkhöz képest. A clusterszolgál- 
tatáshoz képest a telepítés bármilyen sorrendben történhet, 
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vagyis akár utólag is dönthetünk úgy, hogy WINS-t, vagy DHCP- 
t fürtözünk. Arra persze ügyelni kell, hogy mindkét állomáson 
telepítsük a szolgáltatásokat. A varázsló rákérdez a függőségek- 
re (fizikai lemez, hálózati név, IP cím), továbbá definiálnunk 
kell az adatbázisok helyét, amelyeknek természetesen egy fizi- 
kai lemez fürterőforráson kell elhelyezkedniük. Néhány aprósá- 
got azért még érdemes megjegyezni. 

A DHCP szolgáltatást hitelesítenünk kell, amennyiben Active 
Directoryt használunk. Figyeljünk, hogy a hitelesítés alatt ne az 
aktuális állomás, hanem a virtuális kiszolgáló IP címét jegyezze be 
a DHCP Administrator, különben az átköltözésnél gondok lesznek. 
A WINS szolgáltatásnál ügyelni kell, hogy a fürtkiszolgáló általá- 
ban ,multihomed" számítógép. A legegyszerűbb, ha a privát háló- 
zaton letiltjuk a NetBios interface-t, ahogy azt a 0193890 is írja. 
A WINS beállítható úgy, hogy másolatot készítsen a saját adat- 
bázisáról. Az adatbázis megsérülése, vagy elvesztése esetén ez 
hasznos lehet. Csakhogy a fürtnél a másolatnak is közös leme- 
zen kell elhelyezkednie, amelyet mindkét állomás elér, vagyis a 
másolat együtt veszne az eredetivel. A 0283290 választ ad a 
problémára - de erről még szó esik majd a következő cikkekben. 
A két szolgáltatással kapcsolatban jogosan vetődik fel a kérdés: 
miért vesződött a Microsoft a fürtözéssel, hisz mindkettőnél lé- 
tezik jól működő, nem cluster alapú redundáns konfiguráció is? 
A válasz egyszerű: a két szolgáltatás tranzakcióalapú adat- 
báziskezelést végez. Íme, itt a példa, hogyan lehet fürtkompatibilis 
alkalmazást írni. Persze nem csak ez volt az egyetlen érv. A WINS 
és a DHCP, bár kicsi és láthatatlan szolgáltatások, mégis az IP ala- 
pú Windows hálózatok alappillérei. Azok pedig legyenek nagyon 
megbízhatóak. Nos, a Windows 2000 megjelenésével azok lettek. 
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Az elmúlt négy cikkben a RIS-t elég jól megismerhettük minden oldalról, a mostani cikk 
ráadás. Nem létfontosságú, de azért hasznos dolgokról lesz szó. A cikk első felében a 
telepítő elindításához használt varázsló, a CIW képernyőiről lesz szó - ismerkedünk 
velük, majd megpróbáljuk átformálni őket. A másodikban megnézzük több telephelyes 
környezetben a RIS kiszolgálók elhelyezését, a szinkronizálás lehetőségeit. 


Ügyféltelepítő varázsló (Client Installation Wizard — CIW) 
képernyők 

Ezek a képernyők jelennek meg alapértelmezésben a RIS ügyfe- 
lek telepítésének kezdetén. Sajnos a RIS-es ügyféltelepítés ezen 
részét nem lehet teljesen automatizálni, minimális beavatkozás- 
ra itt mindenképp szükség van, de ha egyszer végre elindul a te- 
lepítő akkor nyugodtan magára hagyhatjuk a masinát. 

A RIS kiszolgáló CIW képernyői alapértelmezett telepítés esetén 
a kiszolgáló MRemotelnstallYOSChoosery) alatt levő, nyelvi ver- 
ziónak megfelelő könyvtárában találhatók, kivéve egyet, mert 
az rögtön az OSChooser könyvtárban található. Ez nem más mint 
a welcome.osc, ami mindig a legelső képernyő. Van itt mégegy 
fájl a multilng.osc, ami nem más mint egy módosított welcome.osc. 
Erre bizony szükségünk lehet, ha például a RIS kiszolgálónak 
elállítottuk a területi beállításait. Ha mondjuk egy angol verzió- 
jú Windows 2000 kiszolgálón a területi beállítás magyar, akkor 
a RIS ügyfél telepítésekor egy szép hibaüzenettel elszáll a tele- 
pítés mindjárt az első képernyő után, ugyanis a RIS kiszolgáló 
ilyenkor automatikusan az OSChoosertHungarian könyvtárban 
levő CIW képernyőket akarja használni az ügyfél. Ezt a hibát el- 
kerülhetjük, ha a multilng.osc-t átnevezzük welcome.osc-re. Ek- 
kor az első képernyő egy nyelvválasztó képernyő lesz. 

Mielőtt belenyúlnánk a képernyőfájlokba, nézzük meg őket sor- 
rendben, ahogy következnek. 

A legelső képernyő a welcome.osc, ahogy az előbb mondtam, ez 
mindenképp szükséges. Innen egy [Enter] vezet tovább. 

Jön a logon.osc. Gondolom nem nehéz kitalálni, hogy ez egy 
bejelentkező lépernyő, meg kell adnunk felhasználót, jelszót és 
tartománynevet a bejelentkezéshez. 

Az autentikáció után alapértelmezés szerint a choice.osc jelenik 
meg, a következő választási lehetőségekkel: 
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Automatic Setup - senki nem lepődik meg, ha azt mondom, 
hogy ezzel rögtön elindíthatjuk a telepítést. Ezt választva az 
osauto.osc lesz a következő képernyő, ahol a lehetséges telepí- 
tőkészletekből választhatunk. 

Custom Setup - ez a menüpont a custom.osc-t fogja meghívni. 
Ezt választva lehetőségünk van arra, hogy a telepítőnek egyedi 
információkat adjunk át, így például a gépnevet, helyi rendszer- 
gazda jelszót, vagy akár képernyő felbontáshoz beállításokat. 
Ezzel kicsit később még részletesen foglalkozunk. 

Restart a Previous Setup Attempt - Egy előzőleg megszakadt te- 
lepítést folytathatunk. Mit is jelent ez? A telepítés során a RIS kiszol- 
gálón átmenetileg tárolódik minden ügyfélhez (Remotelnstallitmp 
könyvtárban a GUID-nak megfelelő sif kiterjesztésű válaszfájl, ami 
nem más, mint az adott gép telepítéséhez ténylegesen használt fájl. 
Ha ezt a menüpontot választjuk, akkor az előzőleg már létrehozott 
egyedi SIF fájl alapján fogja az ügyfelet telepíteni. 

Maintenance and Troubleshooting - Itt elvileg BIOS frissítéseket, 
illetve egyéb diagnosztikai programokat választhatnánk, ha lenné- 
nek. Ilyen programokat többnyire OEM gyártóktól lehet beszerezni. 
Fontos megjegyezni, hogy ezt az egész képernyőt kihagyhatjuk, 
vagy beállíthatjuk, hogy csak egyes menüpontok legyenek elér- 
hetőek. Ezt a Group Policyben kell módosítani. 


Choice Options Properties [ejed 


Policy ] 
d Choice Screen Options 


Set the policy for the options available to users during the client installation 











wizard. 
Automatic Setup Custom Setup 
C Allow C Allow 
C Dont care C Dont care 
(a á 6 Deny 
Restart Setup Tools 
C áAllow C Allove 
C Dont care C Dont care 
(6 Deny 6 Deny 
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5 Policy Wser Configuration Windows Settings IRemote 
Installation Services 
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Ha mindent megtiltunk, mint a fentebb látható ké- 

.. — pen, akkor nem is jelenik meg a choice.osc, hanem 
4 egyből a rendelkezésre álló telepítő készletek listá- 
ját láthatjuk - az oschoice.osc képernyőt. 

Az choice.osc után a checkguid.osc jön sorban és csendben, 
látható jel nélkül ellenőrzi az Active Directoryban az ügyfél GUID- 
ot. Ha nem talál az AD-ban azonos GUID-dal és névvel objektumot, 
akkor jön az oschoice.osc a választható telepítőkészletek listájával. 
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5 oschoice.osc 


A felhasználó itt kiválasztja, mit is óhajt telepíteni. Mivel a ki- 
szolgálón levő SIF fájlok NTFS jogosultsá- 
gaitól függ, mi jelenik itt meg a felhaszná- 
lónak, nagyon egyszerűen szabályozható a 
hozzáférés. Amelyik SIF fájlhoz legalább 

5 E. ZBODY lefts5 right:755 
READ joga van az előzőleg bejelentkezett br 
felhasználónak, azok megjelennek itt a lis- 
tában, a többiek pedig nem. 
Miután kiválasztottuk a telepítőkészletet és 
aEntereltünk", megjelenik egy figyelmeztető 
képernyő, a warning.osc, ami arra figyelmez- 
tet, hogy a helyi merevlemez formázása követ- 
kezik. Ha ezen is továbblépünk, még megjele- 
nik egy összegző képernyő, az install.osc ame-  "zintenan 
£/FORM: 


lyen az ügyfél és a RIS kiszolgáló neve, vala-  §/7? 
£BR2 


LOSCML: 


AP left:r85 

AFORM2 

ASELECT SIZE5105 
SOPTION VALUES"OSAUTOT 


Automatic Setuj 
LOPTION VALUE CUSTOM" 


Custom Setup 


and specify where the computer account will 
Select this option if you are setting up this computer for someone else within your company."5 


úgy tudjuk egyedivé tenni a telepítést, hogy nem kell több te- 
lepítőkészletet létrehoznunk. Arra gondolok, hogy például ha 
nem akarjuk a helyi rendszergazda jelszavát beletenni a SIF fájl- 
ba, vagy az adott géphez kötött monitor miatt más képernyőfel- 
bontást szeretnénk beállítani, akkor saját gyártású CIW képer- 
nyőkkel bővíthetjük a varázslót a cél elérése érdekében. 

A CIW képernyők tulajdonképpen OSCML (OSChooser Markup 
Language) nyelven íródott szöveges állományok .osc kiterjesz- 
téssel. Az OSCML a HTML 2.0 verziójához hasonlít leginkább. Az 
OSCML-bem használatos jelekre csak annyira térek ki, amennyi- 
re a példához szükséges, a Windows 2000 Resource Kit és RIS- 
ről szóló White Paper is foglalkozik vele részletesen. 

Nézzünk inkább konkrét példát. Vegyük azt az egyszerű esetet, 
amikor minden géphez közvetlenül a telepítés előtt szeretnénk 
beállítani a képernyő tulajdonságait. 

Ehhez nem kell mást tenni, mint létrehozni egy - mondjuk - 
display.osc nevű képernyőt és meg kell változtatni a choice.osc-t. 
Az alapértelmezett .osc képernyők szerkesztése előtt feltétlenül 
készítsünk másolatot az eredeti fájlokról, például a ".orig kiter- 
jesztést használva. 

Egyszerű szövegszerkesztő, például a Notepad.exe használatával 
nyissuk meg a Choice.osc fájlt. A következő ábra az alap- 
értelmezett beállításokat mutatja. 


LMETA KEYSF3 ACTIONS"REBOOT": 

AMETA KEY5F1 HREF5"CHOICHLP"3 

-META SERVER ACTION-"DNRESET"3 
AMETA SERVER ACTIONZ"FILTER CHOICE"2 
LTITLE; Client Installation wizard 
SFOOTER2 — (ENTER] continue 


Main Menus/TITLEs 


[Fi] help (F3] restart computerc/FOOTER3 


Use the arrow keys to select one of the following options :cbrs 


TIP-"This is the easiest way to instal] an operating system on your 


computer. Most installation options are already configured by your network administrator." 


TIPe"with this option, you can define a jnigye name for this computer 
be created within the directory service, 


LOPTION VALUES"RESTART" TIPe"A previous remote insrallation attempt has been detected on this 
computer, Select this option to restart a previously started installation." 

Restart a Previous Setup Attempt 

LOPTION VALUEs"TOOLS" TIP:"This option gives you access to tools for keeping your computer 
up-to-date and for troubleshooting problems.": 

Maintenance and Troubleshooting 


mint az ügyfél GUID olvasható le. Ha ezen a . Ssotosoeseription: e/BoLDsánbspánbsp 
PAREAZ 


LTIPARI 
S/BODY3 


ponton is továbblépünk, valóban elkezdődik a 
£/OSCML: 


telepítés, és innen már tényleg automatizált a 

folyamat. 

Van az OSChooserVanguage könyvtárban még egy sor .osc kiter- 
jesztésű fájl. Minden képernyőhöz van súgó, valamint a hiba- 
üzeneteket tartalmazó képernyők is itt találhatóak (pl. a 
00004e28.osc, amely bejelentkezési hiba esetén jelenik meg, ha 
helytelen a felhasználói név vagy a jelszó). 


Csináld magad CIW képernyők 
A RIS telepítővel adott CIW képernyőket saját igényeink szerint 
alakíthatjuk, akár több információt is bevihetünk itt, amellyel 


working with wi 
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Meg kell változtatni az -zOPTION VALUE-"OSAUTO" 5 sort úgy, 
hogy a megfelelő képernyőre ugorjon, ami az Oschoice.osc. Te- 
hát cOPTION VALUE-"OSAUTO" : helyébe az cOPTION 
VALUE-"OSCHOICE" 5 lép. 

Ez lehetővé teszi, hogy kiválasszuk a telepítő készletet, még 
mielőtt a felhasználónak bármiféle információt meg kellene ad- 
nia. Át kell írni a leírást is (TIP- ) , majd a megjelenítendő részt 
Automatic Setup"-ról mondjuk , Windows 2000 Setup"-ra. Az 
egyedi választást tartalmazó sort távolítsuk el, ez az OPTION 
VALUE-"CUSTOM" 5 kezdetű. 

A változtatások után így néz ki a fájl: 


ndcús Z RUUS. ad. 








LOSCML2 
META KEY-F3 ACTION-"REBOOT"5 






,META SERVER ACTION- 
LTITLEZ Client Installation wizard 
SFOOTERZ CENTER] continue 

BODY left-5 right-75z 

cbrs 

cbrz 

Use the arrow keys to select one of the following options :cbrs 
-P laft-8s 

ASFORMZ 
SELECT SIZI 
SOPTION VALUI 


[F1) help 
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windows 2000 Setup 


LZOPTION VALUEzs"RESTART" TIPz"A previous remote installation attempt has been detected on this 
computer. Select this option to restart a previously started installation." 


Restart a Previous Setup Attempt 


SOPTION VALUES"TOOLS" TIP-"This option gives ybu access to tools for keeping your computer 


up-to-date and for troubleshooting problems." 
Maintenance and Troubleshooting 

A/SELECT: 

S/FORM 

£/P2 

LBR2 

-BOLO:Deseript ion: /BOLDsénbspánbsp 

STIPAREAZ 

/BODY3 

S/OSCML3 


9 Az új choice.osc , hátulról" 


A következő ábrán azt látjuk, hogy a CIW-t futtató ügyfélnek mi 
fog megjelenni, ha a fenti új oschoice.osc-t használjuk: 


Hain Henu 


Client Installation Wizard 





TENTERI continut (F11 help TF3] restart computer 


a A módosított choice.osc , elölről" 


Ha a felhasználó a Windows 2000 Setup menüpontot választja, 
akkor a következő képernyőn a kiszolgálón tárolt telepítőkész- 
letek listája jelenik meg. Mivel az Oschoice.osc fájl csak a 
Template alkönyvtárat nézi át SIF állományokat keresve, ezt a 
képernyőt nem kell módosítani. 

Második lépésként hozzunk létre a display.osc-t. A legegyszerűbb az, 
ha egy meglevő képernyőt módosítunk, mondjuk a custom.osc-t. 


LOSCML: 

AMETA KEYsFLl HREF5"CUSTHELP5 

AMETA KEYSF3 ACTIONZ"REBOOT"5 

META KEY2ESC HREF5"CHOICE" 

TITLE; Client Installation wizard 

AFOOTER: tENTNAT, continue (Esc) go back [F1] help 

ABODY lefts5 righte75z 

LBR3 

ABR: 98 

Please enter your desíred Display settings or accept the defaults below. 
Rz 


"X-res" VALUEs640 SIZEs4 MAXLENGTH545-ABR3 
-res" VALUE-480 SIZE-4 MAXLENGTH-43cBRI 
ZINPUT NAME-"refresh" VALUES6Ü SIZE-3 MAXLENGTH-35-BR3 





£/FORM: 


BR: 
-BOLD:Examples : 6/BOLD2£BR2 
X resolution: 1024BR5 
Y resolution: 768-BR: 
Refresh Rate: 70LBR5 
2BRZ 
k/Bopys 
S/ÓSCML: 


5 display.osc , hátulról" 


vorking with 


[F3] restart computerc/FOOTER5 


OSCHOICE" TIP-"This is the easiest way to install an operating system on your 
computer. Most installation options are already configured by your network administrator." 


Custom Setupc/TITLEZ 
[F3] restart computerc/FOOTER2 


vindowa 7 


A következő ábrán láthatjuk, ho- hg" 
gyan jelenik meg a Display.osc tú 


main menuszririez — képernyő az telepítéskor. 


ELL e ta 


restart conputer. 


o Ezt látja a felhasználó 


Ezen a képernyőn lehet testreszabni a képernyő beállításait. A 
beírható értékek mellett megadhatunk a felhasználónak egy 
alapértelmezett értéket. Ha csak az ENTER-t nyomjuk meg, a ké- 
pernyő felbontása 640x480 lesz. 

A példában szereplő display.osc a következő változókat továb- 
bítja a BINL szolgáltatásnak: 

X-Res - A képernyő vízszintes felbontása 

Y-Res - A képernyő függőleges felbontása 

Refresh — A képernyő frissítési frekvenciája 

Ahhoz, hogy a megadott értékeket figyelembe is vegye a telepí- 
tő, módosítanunk kell a RIS kiszolgálón lévő telepítőkészlet(ek) 
Templates alkönyvtáraiban lévő mintá(ka)t. A SIF fájlokban a vál- 
tozók 99 jelek közé írva szerepelnek. A példánál maradva az álta- 
lunk beadagolt változók a [Display] szakaszba kerülnek be: 
Configotdartogon - 0 

SÁSSSET s E leget 

YResolution z gY-resxs 


vRefresh - Xkrefreshkg 
Autoconfirm a 1 


Nincs más hátra, mint az elkészített display.osc-t be kell építe- 
ni a meglevő varázslók közé. Ezt legegyszerűbben úgy tehetjük 
meg, hogy az oschoice.osc-ben a cFORM ACTION-"WARNING": 
sort módosítjuk c-FORM ACTION-"DISPLAY": -re, így a telepítő- 
készlet kiválasztása után a beépített display.osc fog megjelenni. 
A fenti csupán egy egyszerű példa volt a változtatásra, azonban 
felügyelet nélküli válaszfájlokban megadható valamennyi beállítás 
számára létrehozhatunk képernyőt, amely a 
BINL közvetítésével a mintaállományba írja 
azokat. Így automatizálható, illetve finom- 
hangolható a telepítő anélkül, hogy minden 
lehetséges esethez külön mintát készítenénk. 
Akit az ismertetett példa felcsigázott, annak 
tudom ajánlani a Windows 2000 Resource Kit- 
et, valamint a Microsoft webes oldalait, ott 
megtalálja a BINL szolgáltatás és az Oschooser 
belső változóinak teljes listáját, ha az OSCML 
szóra keres. 


RIS kiszolgálók több telephelyen 

Evezzünk most kicsit más vizekre, tágítsuk a látókört, és gondol- 
junk arra mi van akkor, ha több telephelye van egy cégnek, és min- 
denhol RIS kiszolgálókat szeretnénk használni. Ahány telephely 
annyiszor kell végigcsinálni minden változtatást? Feltétlenül kell 
minden telephelyre RIS kiszolgáló? Mi van a DHCP-vel és a DNS-sel? 
Azonnal sok-sok válaszra váró kérdés merül fel. Nézzük csak sorban. 
Talán a legelső RIS cikkben volt arról szó, hogy a RIS működésé- 
hez milyen infrastruktúra szükséges. A RIS kiszolgálók elhelyezé- 
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sénél ezt is figyelembe kell venni. Csak emlékezte- 
tőül mondom, 3 dolog feltétlenül kell: Active 
Directory, DNS és DHCP. 

Az Active Directory és a DNS mint követelmény több telep- 
hely esetén sem okoz problémát, mert az alhálózatok közti útvá- 

lasztók átengedik ezeket a kéréseket, azonban a DHCP egy kicsit más. 

Kiveséztük a legelső cikkben a RIS ügyfél és a DHCP közt folyó pár- 

beszédet is. Most csak annyit, hogy az ügyfél DHCP Discover broad- 

castot küld DHCP és RIS kiszolgálót keresve. Ezzel nincs probléma 
akkor, ha minden telephelyen/alhálózaton van egy-egy DHCP kiszol- 
gáló. Az útválasztók alapértelmezésben nem engedik át a broadcast 
üzeneteket, ezért több telephelyes/alhálózatos környezetben bizto- 
sítanunk kell, hogy a DHCP kérések eljussanak a DHCP kiszolgálóhoz. 

Ehhez vagy az útválasztó beállításait változtatjuk meg, vagy DHCP 

Relay Agentet kell telepíteni minden telephelyre/alhálózatra. 

Meghatározza a RIS kiszolgálók elhelyezését a telephelyek közti 

összeköttetések kapacitása is. Nyilvánvaló, hogy kis átviteli sebes- 

ség mellett senki nem fog távoli telephelyre RIS segítségével ope- 
rációs rendszert telepíteni, ilyenkor bizony minden olyan telep- 
helyre RIS kiszolgálót kell telepíteni, ahol azt használni is akarják. 

Ez riasztó lehet sok telephely esetén, hisz elég sok dolgot kell 

beállítani ahhoz, hogy rendesen működjön a felügyelet nélküli 

telepítés. Magában a RIS-ben nincs a szinkronizálásra beépített 
eszköz, rabszolgamunka lenne mindenhol ugyanazt manuálisan 

beállítgatni. Nem is kell, ha okosan használjuk a Windows 2000 

beépített szolgáltatását,a DFS-t - teljes nevén Distributed File 

System. Ezzel sok munkát és időt spórolhatunk meg. 

Egy mondatban összefoglalva: egy RIS kiszolgálót felépítünk az 

igényeknek megfelelően, majd a könyvtárstruktúrát DFS segítsé- 

gével lemásoljuk a többi RIS kiszolgálóra. Az első teljes repliká- 
ció befejeztével a másolatok egyenrangú felekké válnak, bárhol 
változtatunk, az a többi kiszolgálóra replikálódik. 

Nézzük ehhez mit is kell tenni: 

Először is igényeknek megfelelően felépítünk egy RIS kiszolgá- 

lót, azaz kialakítjuk a megfelelő könyvtárstruktúrát. 

Ezután létre kell hozni egy ún. Domain DFS Root-ot, a követke- 

ző módon: 

1. Indítsuk el a Distributed File System MMC snap-int az 
Administrative Toolsból mondjuk a RIS kiszolgálón, vagy 
bármely tartományban levő gépen 

2. Az Action Wew DFS Root varázsló első kérdésénél válasszuk 
ki, hogy Domain DFS Root-ot szeretnénk létrehozni. 

3. Ezután a tartomány neve jelenik meg, amelyben a replikáció 
működni fog. 

4. A következő képernyőn meg kell adni annak az elsődleges 
kiszolgálónak nevét, amelyik a DFS Rootot tartalmazza. A mi 
esetünkben itt az imént létrehozott és beállított RIS kiszol- 
gáló nevét kell megadni. 

5. Ha ezen is túljutottunk, meg kell adni a Root-hoz egy megosz- 
tást, ami egy tetszőleges (üres) könyvtár lehet. 

6. Ezután még nevet és ismertetőt is fűzhetünk a létrehozott 
megosztáshoz. 

7. Az összefoglaló képernyőn is túljutva elkészül a Domain DFS Root. 

Még csak a beállítások harmadánál járunk, második lépésként 

létre kell hozni legalább egy DFS Linket is. 

Az előzőleg létrehozott DFS rooton jobb klikk - New Dfs Link 

segítségével az alábbi módon létrehozzuk az első RIS kiszolgá- 

lónk reminst megosztásához a DFS Linket: 


görkínü urirth 


windows / 


Create a New Dfs Link 


When a user opens [NHELLARootAlSImages 


Link name: 


fRisSimages 


Send the user to this shared folder: 


[mcserver name) Wreminsű Browse... I 


Comment: 


Clients cache this referral for 11800 seconds. 





Cancel I 





5 DFS Link a RIS telepítőkönyvtárhoz 


Ehhez a DFS Linkhez ezek után Replikákat (másolatokat) lehet 
hozzáadni. A példánál maradva a RISImages Linken jobb klikk - 
New Replica menüpontot választva hozzáadjuk sorban az összes 
RIS kiszolgáló Reminst megosztásait. 








Add a New Replica eled 


When a user opens [MHELLYRootRISImages 


Sendthe user to this shared folder: 
McRIS Servep veminst Browse... 
Replication Policy 

; 6 [Manual replication 


C Automatic replication 





5 DFS-sel juttatjuk el a telepítőkészleteket a többi RIS 
kiszolgálóra 


Ezek után nincs más dolgunk mint bekapcsolni a replikációt. Ezt 
úgy tehetjük meg - a példánál maradva-, hogy a RISImages DFS 
Linken jobb klikk - Replication Policy menüt választjuk, ott a 
legelőször felépített RIS kiszolgálót elsődlegessé tesszük a Set 
Master gombbal, majd a többi kiszolgálót az Enable gomb se- 
gítségével bekapcsoljuk a replikációba. 


Zárszó 

A RIS cikksorozat itt véget ér, remélem sok hasznos információ- 
val gazdagodtak olvasóim. Az elméleti és a gyakorlati ismerte- 
tés mellett igyekeztem minél több, a mindennapi gyakorlatban 
is jól használható tippet adni amelyek segítségével a RIS min- 
den lehetőségét valóban ki lehet aknázni. Aki úgy érzi nem ta- 
lált meg valamit a cikkekben a RIS-ről, annak ajánlom figyelmé- 
be a Windows 2000 Resource Kitet, vagy a Microsoft technet-et. 


Dorner Csilla 
MCSE 


SDDB8B. HA: 


Függőségi viszonyok 
(I. rész) - At least one service 


egy szeg miatt a patkó elveszett, 
patkó miatt a ló is elveszett, 
a ló miatt a huszár elveszett, 
huszár miatt a csata elveszett, 
csata miatt az ország elveszett, - 
ennyit tesz, lám, egy ici-pici szeg! 
Angol gyermekvers 


Egyik hajnalban ülök egy kiszolgáló előtt, mely már a nyolca- 
dik kört bootolja, de csak nem akar helyrejönni. Izgatottan vá- 
rom, kilencedszer is mondja-e, hogy ,at least one service 
failed to start", vagy végre hazamehetünk. Íme az ominózus 
hibaüzenet, melynek felbukkanásakor minden lehetséges: vagy 
egy, vagy egyezer szolgáltatás nem indult el: 





§ 3 
/1 At least one service or driver failed during system startup, Use Event Viewer to 
examine the event log for details. 





5 Legalább egy szolgáltatás nem indult el. Egy? Kettő? 
Vagy több? Ezt az Event Logból olvashatjuk ki. 


A Windows belső felépítése a fürt tükrében 

A Farkasokkal táncoló... sorozatban igen gyakran esik szó virtuá- 
lis kiszolgálókról. Emlékeztetőül: ezek azok a ,masinák", melyek 
önálló gépként, saját névvel és IP címmel látszanak a hálózaton, 
ám valójában nincs mögöttük egy meghatározott vas, amire rá- 
bökhetnénk, hogy ,íme, ez itt a 000 nevű kiszolgálónk". Ponto- 
sabban nem egy meghatározott vas van alattuk, hanem - 
Advanced Server esetén - kettő. A fürt által futtatott virtuális ki- 
szolgálókat magunk építgetjük össze. Mi kell hozzá? Ha adatokat 
szeretnénk tárolni rajta, kell egy lemez. Ha hálózaton keresztül is 
elérhetővé kívánjuk tenni, kell TCP/IP, és egy IP cím. Ha a fel- 
használók kegyeiben szeretnénk járni, a gépnek NetBIOS nevet is 
adunk. Erre az alapra azután jöhetnek a további szolgáltatások. 
Ha az eddig felsorolt három erőforrást (lemez, IP cím, NetBIOS 
név) egyszerre, egy időben indítjuk, a NetBIOS név nem születik 
meg, mert IP cím híján a névnek sincs értelme - azaz szolgálta- 
tásaink között függőségi viszony fedezhető fel, ami az indítási 
sorrendjüket is meghatározza: az IP címtől függ a név. Érdekes, 
hogy míg virtuális kiszolgálóinkat szabadon tákolhatjuk össze 
(maximum nem indul el) , addig fizikai, telepített operációs rend- 
szereinkbe gyárilag belekerül a szolgáltatások helyes indítási 
sorrendje. A gyakran látott ,at least one..." hiba pedig valóban 
azt jelenti, amit: legalább egy szolgáltatás nem indult el. De 
hogy pontosan hány, azt a függőségi útvonalak mentén oszlado- 
zó szolgáltatástetemek összeszámlálásával tudhatjuk meg. 

A fenti ábra egy olyan - Exchange 2000 Servert futtató - tagki- 
szolgálóról készült, amelyik áramszünet után egyszerre indult a 
nála lassabb tartományvezérlővel, így az Exchange indítása idő- 
ben korábbra esett, minthogy a tartományvezérlő önmagára ta- 


working vith 


windows / 








lált volna. Ebből következően a tartományi fiókkal futó 
Exchange szolgáltatások nem tudtak bejelentkezni. Ebben az 
esetben az ,at least one.." valójában négy, illetve a mellékzön- 
gékkel együtt inkább nyolc: 


GED 


System 251 event(s) 

Type Toste Time Sos 

E eror 2002.03.03. 172018 Bromser 

Ő Warning 2002.03.03. 170901 S 

information . 2002.03.03. Appication Papup 
Deror 2002.03.03. Service Control Manager 
Éj error 2002.03.03. 














2002. 
2002. 

2002.03.03. 
2002.03.03. 
2002.03.03. 
2002.03.03. 
2002.03.03. 
2002.03.03. 
2002.03.03. 
2002.03.03. 
2002.03.03. 





5 Ez a rendszerindítás nem valami fényesen sikerült! A tar- 
tományvezérlő hiánya miatt Windows 2000 helyett egy fél- 
karú rabló került a kezünk közé. 


Alulról felfelé a következő hibák olvashatók az eseménynaplóban: 

"0 A NetLogon szolgáltatás nem talált tartományvezérlőt 

8 A W32Time nem talált forrást (tartományvezérlőt) a rendszer- 
óra szinkronizációjához 

0 A Service Control Manager nem tudta elindítani az Exchange 
szolgáltatásait (System Attendant, Information Store, MTA, 
POP3, IMAP4) 

5 A W3SVC (Internet Information Server) nem tudta felvenni az 
Outlook Web Access könyvtárakat (Exadmin, Exchange, 
Public) az M: meghajtóról 

Más hiba nincs. Szerencsére ebben az esetben a , hiba" kijavítá- 

sa nem áll másból, mint a kiszolgáló újraindításából: mostanra 

elindult a DC, és mind a tizenvalahány üzenet megszűnik. 


A Service Control Manager 

A Windows rendszerindítását a bootolás korai szakaszában az 
NTLDR, később az NTOSKRNL, majd a Service Control Manager 
végzi. Ez utóbbi felelős a szolgáltatások megfelelő sorrendű in- 
dításáért - mellesleg a SYSTEM32 könyvtárban, a SERVICES.EXE 
fájlban lakik. 

A szolgáltatások indítási sorrendjét a regisztrációs adatbázis 
tartalmazza - minden szolgáltatás tudja magáról, hogy ő ki/mi 
után következik. 

Vessünk egy pillantást a függőségi viszonyokra, indítsuk el az 
Administrative Tools/Services eszközt, s jobb gombbal csiklandoz- 
zuk meg mondjuk az RPC szolgáltatást, majd kattintsunk a 
Dependencies (függőségek) fülre. A következő ábra alsó részében 
megfigyelhetjük, hogy mely szolgáltatások indulása hiúsul meg, ha 
az RPC befuccsol. A Windows Installertől az RRAS-on át a Protected 
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Storage-ig minden megtalálható itt, kivéve a Server és 
a Workstation. (Erről jut eszembe, ha minden igaz, lesz 
egy bátor jelentkezőnk arra a feladatra, hogy a Windows 
szolgáltatásait egytől egyig elmagyarázza nekünk, hogy 
tudjuk, vajon mire való - pédául - a Distributed Link Tracking, és 
mit veszítünk/nyerünk azzal, ha leállítjuk. ) 
Visszatérve: ez azt jelenti, hogy ha az RPC nem indul el, akkor 
(at least...) mintegy harminc további komponens sem! 


SZE áa 


General / Log On ! Recovery ! . Dependencies 


Some services depend on other services, system drivers and load order 
groups. If a system component is stopped or is not running properly, 
dependent services can be affected. 


ke Remote Procedure Call (RPC) 


The following system components ebet on this service 


NEZ Ez koround inteligent Transfer Sewics ] 8 
a égy COM: Event System 
(5) 6fy COM: System Application 
64 Cryptographic Services 
5. 6fy Distributed Link Tracking Client 
! 6-6 Distributed Transaction Coordinator 
Fa ÉRa Firor Renortina Servinm 





5 Az RPC-től a következő szolgáltatások függnek: szinte mind! 


Még szerencse, hogy a párbeszédpanel felső listájának tanúsága sze- 
rint az RPC semmitől sem függ, tehát garantáltan mindig elindul. 
Távolról azonban már nem biztos, hogy hozzá tudunk csatlakoz- 
ni, ugyanis az RPC kényes a hálózat helyes működésére. Ha az 
alábbi hibaüzenetek valamelyikével találkozunk, elsősorban há- 
lózati hibára gyanakodjunk! 


The RPC server is too busy to complete this 
operation. 


és 
The RPC server is unavailable. 


Nézzünk egy megtörtént esetet, mi állhat a hibaüzenet hátterében: 

1. hálózati hiba miatt meghiúsul az időszinkron a tartományve- 
zérlők között 

2. ha az órák 5 percnél jobban szétcsúsznak, a Kerberos beint 
nekünk 

3. ha nem megy a Kerberos, a legkülönbözőbb jelenségek ütik 
fel fejüket, többek között a rendszergazda... 

4. ,The RPC server is unavailable" üzeneteket kap, valahányszor 
rendszergazdai eszközt indít 

5. ez odáig fajulhat, hogy leáll az Active Directory replikáció, 
hisz az (jobb híján) RPC alapú 


working with 


windows / 


A Service Control Manager működése módosítható, befolyásol- 
ható, ha tudjuk, hol tárolódnak a rendszerben a függőséget 
leíró adatok. Nem máshol, mint a regisztrációs adatbázisban. 
Mielőtt azonban nekiesnénk, keressünk egy jó példát, vajon mi 
a csudáért lenne érdemes beavatkozni a szolgáltatások egymás- 
ra épülésébe. Nekem van egy ötletem! (Remélem Redmond is ol- 
vassa ezt a cikket, és az ötletből beépített szolgáltatás válik...) 


Last Known Good és System Restore - röviden 

Bizonyára sokan ismerik a Windows NT óta meglévő remek szol- 
gáltatást, mellyel szétkonfigurált rendszereinket vissza lehet 
vinni egy korábbi, talán még működőképes állapotba: ez a Last 
Known Good indítás, mely ha mást nem is, de a regisztrációs 
adatbázis CurrentControlSet részét könnyen helyreállíthatóvá te- 
szi. Ha szétparamétereztünk valamit, ettől visszaparaméterező- 
dik. (Emlékeztetőül: bootoláskor szóközt, majd ,,L" betűt ütünk.) 
A Windows XP emellett tartalmaz egy mindent-mentő, úgynevezett 
System Restore visszaállítási lehetőséget is, mely a Windows 2000- 
féle Sytem File Checker (-rendszerfájl-visszamásoló) szolgáltatás ki- 
bővítése tetszőleges visszaállítási pontokkal és csinos varázslófelü- 
lettel. (XP kezdőknek: Accessories-zSystem Tools-oSystem Restore). 
Nomármost ez mind szép és jó, de nekem kevés. A Last Known 
Good (na jó, és a Rollback Driver) tökéletesen megfelelő lenne 
számomra, ha nem úgy működne, ahogy. Évszázadok óta az a 
baja, hogy ostobaság rám bízni annak megállapítását, vajon egy 
adott rendszerindítás hibátlan volt-e, ha egyszer a Service 
Control Manager pontosan tudja, és jelzi az indítási hibákat (at 
least one... ugyebár). 1994, azaz Windows NT 3.1 óta azonban 
változatlanul ugyanúgy dől el, hogy egy beállításturmix helyes- 
e: vajon sikeresen be tud-e valaki jelentkezni? A hibátlan beje- 
lentkezés pecsételi meg az adott konfiguráció sorsát: tekintsük 
jónak! A bejelentkezésünk a háttérben egyben minőségel- 
lenőrzés is: ,Passed" pecsétet kap az adott CurrentControlSet. 
Könyörgöm, ekkor még ne tekintsük jónak! Hisz a sikeres beje- 
lentkezés után még javában indulnak a szolgáltatások, az SOL 
Server egy, az Exchange három perccel a bejelentkezés után vé- 
gez, amikorra mi már nemcsak hogy sikeresen bejelentkeztünk, 
hanem már egy parti WinMine-t is elveszítettünk. 


Kedves Bill! 
Javaslatom a következő: legyen a Windowsban egy olyan szolgál- 
tatás, ami a többi után, azoktól függően indulna el, és ez állítsa 
át a Last Known Good jelzést a beállításokon. Ezzel a megoldás- 
sal ugyanis egy csapásra megoldódik a meo-dilemma. Ha ,,at least 
one service failed to start", akkor ez utóbbi sem indul el, hisz 
függ a többitől. S ha nem indul el, nem is pecsételi le feleslege- 
sen (sőt hibásan) a CurrentControlSetet. 
Üdvözlettel 
Fóti Marcell 


Ezek után pillantsunk bele a regisztrációs adatbázisba. 
A szolgáltatások beállításai 
Szemeljük ki áldozatként a jó öreg Browse szolgáltatást. Tudják, 


ez tehető felelőssé a Network Neighborhoodban látottakért. Az 
ő beállításai így néznek ki: 
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Lanmanworkstatron LanmanServer 
Mantains an usdated ket of comosters on the network! 
Computer Browser 

0700000001 (1) 

zőystemftoottéjőystemöztsvehest exe -k netsves 


My ComputerHKEY LOCAL MACHINESYSTEMCurrentControlsettserviseslőronser 


a Egy kiragadott Windows szolgáltatás beállításai 


A fenti ábráról minket a DependOnGroup és DependOnService 
sorok érdekelnek. Ez írja le, hogy az adott szolgáltatás milyen 
egyéb komponensektől függ. A Browse indulása például mind a 
LanmanWorkstation, mind pedig a LanmanServer futásától függ. 
(Az is megérne egy cikket, hogy mitől Lanman, mikor lassacskán 
a NetBIOS-tól tökéletesen megszabadulunk). Ilyen egyszerű. Ha 
Bill megfogadja a tanácsomat, akkor a Windows .NET 2005-ben 
találunk majd egy LastknownGood nevű szolgáltatást (nomeg 
egy varázslót, hogy ne regedittel kelljen beállítani a működését) . 
Az egyes szolgáltatások beállításai alkönyvtárakban (alkulcsok- 
ban) találhatók. A Browser például a Parameters kulcs alól olvas- 
. sa ki, hogy egyáltalán szükség van-e rá (MaintainServerList érték) , 
a LanmanServer pedig saját Shares kulcsába dugja el a megosz- 
tott könyvtárak adatait (könyvtárnév, megosztásjogok stb). 

A Knowledge Base 62 találatot jelez, ha rákeresünk a DependOn- 
Service szóra. Mit érdemes átállítani? A Browser szolgáltatás 
függőségét nem, jottányit sem javul tőle, azonban meglepő mó- 
don a Netlogon bizonyos esetekben módosítandó! Ha egy tarto- 
mányvezérlő egyben saját DNS Servere is, akkor a szolgáltatáso- 
kat érdemes úgy felfűzni, hogy a Netlogon akkor induljon, ami- 
kor a DNS már garantáltan fut. Ehhez a Netlogon szolgáltatás 
DependOnService értékébe a meglévő LanmanWorkstationon kí- 
vül fel kell venni a DNS szolgáltatást is. 


A Services eszköz 

Maradva a Browse szolgáltatásnál, nézzük meg, mit nyújt az 
Administrative Tools-sServices. Először is meg kell találnunk benne 
a Browsert, ami csak másodikra sikerül, mert itt Computer Browser 
a neve. (A fenti registry-ábrán ez a DisplayName sorban olvasható.) 
Hatalmas újdonság, hogy nemcsak egyesével lehet újraindítani 
a szolgáltatásokat, hanem - a függőségek figyelembe vételevel 
- csoportosan is. Erre való a jobbklatty, Restart opció. De most 
lássuk a Browser tulajdonságlapját! 
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Computer Browser Properties ( (ocal Computer) 


- General. LogOn 1 Recovery [/ Dependencies 


Browser 
ben EETESZ 


Maintains an updated list of computers on the 
network and supplies this list to computers 


Service name: 
Display name: 
Desciiptiorc 

Path to executable: 


C-XWINDOWSASystem3Ztsvehost.exe -k netsves 


Startup type: / Autornatic 


Service status: Started 


Paus 


You can specify the start parameters that apply when you start the service 
from here. 








5 Szolgáltatásaink beállításai egytől egyig a regisztrációs 
adatbázisban vannak. Amit ezen a panelen nem lehet átírni 
- azt átvéshetjük Regedittel! 


A legalsó mezőbe olyan indítási paraméterek írhatók, amiket az 
adott program parancssorból elfogadna. Két élő példa: az SOL 
Server különböző üzemmódjait (factory default, minimal stb.) va- 
lamint az Exchange Key Management Server indítási kulcsát 
sszokás" ide beírni. Ez az érték sajnos nem kerül ki automatiku- 
san a registrybe. Ha tartósan használni szeretnénk, írjuk az 
ImagePath végére! 

A következő fülön a szolgáltatás bejelentkezési neve és jelsza- 
va állítható be (melyet a Service Control Manager felír egy cetli- 
re, hogy mindig kéznél legyen neki, valahányszor indítania kell az 
adott programot) . Két beállítási lehetőség van: 





eral[ Log On Recovery ( Dependencies ! 


Gen. 





[]Jállow service to interact with desktop 





O Ihis account: 























5 A szolgáltatás is ,ember", ezért kell neki név és jelszó! 
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At least one service / 
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A Local System jelentése: a szolgáltatás a Windows 
része, nem használ külön felhasználói fiókot. A Win- 
dows korábbi változataiban (NT£ és elődei) a Local 
System egyet jelentett azzal, hogy az adott szolgálta- 
tás nevesített külső kapcsolatot nem kezdeményezhetett 
(a tévhit ellenére anonymoust viszont igen). Ma már ez a korlá- 
tozás is a múlté, ugyanis a Windows 2000 és utódai ilyenkor a 
Computer Accounttal próbálkoznak a hálózaton (emlékezzünk: 
MASINA$). Gyakorlati példával: az MSSOLServer esetében csak 
akkor kell átállítani a futtató felhasználót, ha beindítjuk az SOL 
Mail szolgáltatást, mert ebben az esetben hozzá kell férnie egy 
MAPI postafiókhoz, ami MASINA$-nak általában nem jár. És vé- 
gül a Recovery fül: 


Computer Browser Properties (Local Computer) 





Select the computers response if this service fails. 


First failure: 


Restart the Service ja 


Second failure: Run a Program 


Subseguent failures: Í Restart the Computer . 64 


Reset fail count after: 











Restart service after: 


Run program 
Program: 
[e:Wogolo. bat 


fLeallt a Browsed ] 





Command line parameters: 





CI Appenad fail count to end of command line (/fail-z12) 


Restart Computer Options... 








Cse] Car] 


a Ha a Computer Browser leáll, próbáljuk újraindítani. Ha 
ismét leáll, induljon el egy batchfájl, harmadszorra pedig 
induljon újra a gép 


62002 Joseph Pelrenyi 
BEÁLLÍTOTTUK AZ ÚJ SMART- 
CARD BELÉPTETŐ REND- 
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Kritikus szolgáltatások esetén (például DNS) megfontolandó a 
Windows beépített helyrehozási lehetőségének beállítása. Min- 
den szolgáltatásnak három élete van. Első meghalása után - pél- 
dául - megpróbálhatjuk automatikusan újraindítani. Ha (a fenti 
beállítások esetén) 24 órán belül megint elpukkan, futtathatunk 
egy programot. Vigyázat, a Service Control Manager által indított 
programok felhasználói felületet nem kapnak! Komolyabb eset- 
ben megfontolandó egy VBScript futtatása, mely parancssorból 
átveszi a hiba körülményeit, és akár emailben, akár net send pa- 
ranccsal értesít valakit. Ha a második életét is elpazarolta a szol- 
gáltatás, akkor jöhet a végső megoldás: a gép újraindítása. 

A beállítások tesztelésére a Support Tools eszközkészlet 
KILL.EXE segédparancsát javaslom, bár pont a Browsert nehéz 
így leállítani, hiszen a SvcHost.EXE része. SOL Server, Lotus 
Notes és hasonló, utólag telepített alkalmazások azonban sza- 
badon megdönthetők a segítségével. Így megismerhetjük a 
rendszer reakcióidejét (1 másodpercen belül lefut a Recovery fü- 
lön beállított cselekmény), valamint a tesztelt szolgáltatás 
túlélési képességét is. A KILL egy csodafegyver, használják bát- 
ran! Előtte még véletlenül se mentsék adataikat! 


Fóti Marcell 
marcellf onetacademia.net 


http://vilagokorseg.hu 
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RRAS: 





Open Shortest Path First 


RRAS sorozatunkban utoljára a RIP útválasztási protokollal foglalkoztunk, és 
megállapítottuk hiányosságait: lassú konvergenciáját, hurokérzékenységét, 15 hopos 
korlátját - egyszóval butaságát. A RIP ismert gyengeségeit nem a következő verzió 
kivárásával kell orvosolni, hanem - ha hálózatunk méretével, bonyolultságával a RIP nem 
tud megbirkózni - áttérhetünk egy sokkal fejlettebb útválasztási protokoll, az OSPF használatára 


Az OSPF legnagyobb újdonsága, hogy - ellentétben a RIP-pal -út- 
választóink nem komplett útvonaltáblákat küldenek át a szomszé- 
dos routerre, hanem csak egy icipici táblázatot, melyben az általuk 
ismert hálózati útvonalak adatai szerepelnek: irány, ár, és állapot. 


Open Shortest Path First 

Az [1] címen található RFC tanúsága szerint az OSPF útvonalvá- 
lasztók valójában útvonal tervezők, amit úgy kell értenünk, 
hogy minden egyes router önmagában, intelligensen számítja ki 
egy-egy IP csomag leszállításának optimális útvonalát. A proto- 
koll elnevezésének tükörfordításával: a legrövidebb útvonalat 
nyitja meg az áthaladó csomagok előtt. Az OSPF bonyolult há- 
lózatok lekezelésére is képes. Nemhogy nem borul ki hurkokkal 
terhelt hálózatokban, hanem ott érzi igazán elemében magát. 
Vessünk egy pillantást az alábbi ábrára: 





3 Hurkokkal tarkított vállalati hálózat 


Ilyen hálózatban a RIP valószínűleg pillanatok alatt végezne 
önmagával, pedig ez a hálózat megbízhatóbb csomagtovábbí- 
tást nyújt egyszerűbb társainál, mert ha egy útvonal kiesik, 
szinte biztosan akad más út, melyen a két, sarokba állított szá- 
mítógép kommunikálni tud egymással. Ehhez természetesen az 
kell, hogy vonalszakadás esetén hamar átszámítódjanak a köz- 
benső routerek útvonaltáblái. 

A bal felső gép szeretné megpingelni a jobb alsót. A hálózat jobb 
alsó részében a kereszttel jelölt helyen szakadás van. Mi egyetlen 
szempillantással fel tudjuk mérni, hogy a fekete útválasztónak a 
három lehetséges hálózati útvonal közül csak a vastag vonallal 
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jelzett úton szabad elindítania az alsó gép felé a csomagot: a töb- 
bi út 3-4 router múlva ,eldugul". Igen ám, de az útválasztók nem 
felülről szemlélik a hálózatot, hanem abban benne állnak. Madár- 
távlatból könnyű megtalálni az Eiffel toronyhoz vezető utat, de 
Párizs szűk utcáinak egyikén toporogva a feladat korántsem ilyen 
egyszerű. Mi kell a célpont megtalálásához? Térkép! 


A Link State Table 

Térkép sajnos nincs. Felesleges lenne térképet készíteni olyan vá- 
rosban, ahol egyik pillanatról a másikra új utcák születnek, más ut- 
cákat eltorlaszolnak, megváltozik az utca neve, vagy a végpontja. 
Ehelyett van egy csapatnyi turistánk, akik a város kereszteződései- 
ben állva figyelik az általuk látható utakat, és - ha változás áll be 
- közlik közvetlen szomszédaikkal a hírt: teljes szélességében fel- 
bontották a Rákóczi utat, vagy fizetőssé vált a Lánchíd használata. 
Az egyes útválasztók az általuk kezelt hálózatokról, a vonalak 
állapotáról, áráról stb. táblázatot vezetnek, melynek neve Link 
State Table. Ezt a - lokális helyzetképet tükröző - táblázatocs- 
kát küldik át szomszédaiknak, akik természetesen továbbítják a 
távolabbi útválasztóknak is. Idővel mindegyik útválasztóhoz el- 
jut a többiek által közölt állapottáblázat. És ekkor kezdődik a 
valódi munka: a beérkezett jelentések alapján minden egyes 
router elkészíti saját térképváltozatát, melyben nem fognak 
szerepelni sem a lehetetlen, sem a drága útvonalak. Az előző 
ábrán a fekete vonal valójában nem más, mint a fekete útválasz- 
tó által generált térkép. Egy-egy útválasztó csak a saját hatás- 
körébe tartozó útvonalak használatáról dönt, de a döntést a 
többiek által beküldött Link State Table alapján teszi! 
Közelítsük az ábrát egy kicsit jobban a valósághoz! Színes, 
iMAC-like gépeket vásárolunk, hupikéket, ezüstszürkét és bíbort 
(bár ez utóbbi szín a lapban használt két festék tetszőleges ará- 
nyú kevergetésével sem lesz más, mint szürke). A bal felső mun- 
kaállomás változatlan marad, színpompás gépeinket viszont a 
hálózat különböző pontjaira helyezzük. A fekete útválasztót 
megvizsgálva kiderül, hogy a beérkezett Link State Tablek (LST) 
alapján mindegyik célpont felé tud térképet rajzolni. 


HUS. HA: 


:Svad / 


354TJ UJed 358340US U3ado 


15 


Open Shortest Path First / 


RRAS : 


17 




















5 Az OSPF útválasztó útvonaltáblája különböző célcímeket 
tartalmaz 


Ha megszakítjuk az egyik vonalat, a távoli útválasztók már kül- 
dik is vadonatúj Link State táblájukat, és fekete routerünk ha- 
marosan új térképet készít. 





5 Az OSPF útválasztók gyorsan alkalmazkodnak a megválto- 
zott hálózati felépítéshez 


OSPF fogalommagyarázat 

Ennyi , matematika" talán elég is lesz (Dijkstra bácsi forog a sír- 
jában), mivel nem tartom valószínűnek, hogy közülünk bárki is 
belefogna OSPF implementáció készítésébe. Azonban korántsem 
vagyunk készen. Hátra van még az OSPF környezet ismertetése, 
valamint az RRAS megfelelő beállítása. 

"0 Autonomous System (AS). Az egymással Link State Tablet 
cserélő OSPF útválasztók egy közös Autonomous System ré- 
szei, közös autentikációval, közös állapotinformációval ren- 
delkeznek. Egy hálózaton elvileg lehet egynél több AS is, 
ennek azonban nem sok értelmét látom. 

Area. Nagy hálózatokban érdemes lehet bizonyos zárt leága- 
zások útválasztóit csoportokba foglalni. A csoporton belül 
szabadon áramlik a Link State, kifelé viszont a csoport tag- 
jai egyetlen útválasztónak fognak látszani. Az area nagyon 
hasonló az Active Directory-féle telephelyekhez: kis zárt vi- 
lág, mely a külvilággal általunk definiált módon kommuni- 
kál. Ha a Microsoft nevezte volna el, ma azt mondanánk rá: 
site. Az areakat IP cím szerű, 4 tagból álló számokkal azono- 


ö 
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sítjuk, melyeknek valójában semmi közük semmihez: a rend- 
szergazda hasraütéses módszerrel választhat area azonosító- 
kat. Ha nem definiálunk külön területeket, akkor útválasz- 
tóink az alapértelmezett, 0.0.0.0 azonosítót viselő area tag- 
jai lesznek. Egészen pontosan nem az útválasztók tagjai egy- 
egy areanak, hanem az általuk kezelt vonalak. Ezzel elérhe- 
tő, hogy ha egy router mondjuk három különböző areaba eső 
hálózatot kezel, akkor tulajdonképpen mindháromnak része. 

"8 Range. Egyetlen area egynél több IP tartományt lefedhet. 
Ezt az areahoz rendelhető IP alhálózatokkal adhatjuk meg. 

0 Stub. Stub, vagy végállomás areanak azokat a területeket ne- 
vezzük, melyek útválasztói zárt közösséget alkotnak, külső 
útvonalakat nem tanulnak meg. 

0 Boundary router. Az előző ellentéte. A Boundary, vagy ha- 
tárútválasztó annyi útinformációt gyűjt, amennyit csak tud: 
statikus bejegyzéseket, RIP-et, SNMP-től tanul stb. 

0 Hello protokoll. OSPF útválasztóink automatikusan keresik 
meg társaikat. Címzésmódját tekintve Multicast, azaz a perio- 
dikusan kibocsátott hellózás nem zavarja a hálózat összes gé- 
pét. Alapértelmezésben tíz másodpercenként történik. Szin- 
tén alapértelmezés, hogy ha egy útválasztó négyszer egymás 
után nem válaszol a Hellora, akkor hibásnak kell tekinteni. 

Lássuk ezek után, hogyan kell öszehozni egy OSPF megoldást a 

Windows 2000 beépített RRAS szolgáltatásával! Először is tele- 

pítenünk kell az OSPF protokollt, ami a szokásos módon, az IP 

Routing alatti General fülön jobbklattyintva, a New Routing 

Protocol-lal végezhető el: 
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View , 
Refresh 
Export List... 
3] 


[dd a new routing protocol 


5 Az OSPF telepítése 


Telepítés után azonnal kezelhetjük az areakat, átállíthatjuk út- 
választónkat Boundary routernek, és kiválaszthatjuk, hogy a ha- 
tárvidéken túlról milyen útinformációt gyűjtsön be. Ha az aláb- 
bi ábrapáron az OSPF protokoll tulajdonságlapjának első fülén 
beállítjuk, hogy határvidék-útválasztó legyen, a negyedik fülön 
kiválaszthatjuk, hogy milyen forrásokból tanuljon: 
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5 Határvidék routereken megválaszthatjuk, mit emeljenek 
be a mi hálózatunkra a külvilágból 


Az útválasztó protokoll mindaddig nem indul be, amíg meg nem 
mondjuk neki, hogy mely kártyákon Hellózhat. Ezt az OSPF-en 
jobbkattintva tehetjük meg (New Interface... ) . 
Vegyünk fel tehát egy hálózati kártyát, hogy azon át OSPF 
routereink megkezdhessék aktív hellózásukat: 


Local Area Connection Properties E; 2]xi 


General ] NBMA Neighbors ] advanced] 


Es Open Shottest Path First (OSPF) Interface 
zt 








Arga ID: 0.0.0.0 isa 
Router priority: 1 ker. Cost 2 e] 
PteNöltt (KKT 
Network type 
G Broadcast 
€C Point-to-point 
C  Mon-broadcast multiple access (NBMA) 











5 Hálózati kártya felvétele az OSPF hatásköre alá. Ezen a 
kártyán keresztül tanulni, és tanítani fog 


Hozzá kell rendelnünk egy előre létrehozott areahoz, be kell ál- 
lítani, hogy mekkora eséllyel legyen ő a fő-fő Hellózó (desig- 
nated router priority), valamint hogy a tőle kimenő útinformá- 
ciókon mennyivel növelje meg a metric (cost) értéket. A jelszó- 
ra még visszatérünk, a hálózat típusa ethernet esetén nyilván 
broadcast. Amint ezen a kártyán elindul a Hello, a rutinos rend- 
szergazda nyomban Network Monitort ragad, és megnézi, ho- 
gyan is fest az üzenet a hálózaton. Sorokra tördelve és megrit- 
kítva nézzünk meg egy Hello csomagot! 


Hello ACAPULCO 224.0.0.5 IP 


Az ACAPULCO nevű gép küldte ezt a csomagot a 224.0.0.5-ös 
Multicast (OSPF) címre. Ethernetszinten a célcím így fest: 





ETHERNET: Destination address : 0O2005EOODOODS5 
ETHERNET: . l - Group address 

ETHERNET : . z- Universally administered 
$ address 
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Tehát csoportcím, mégpedig a szabványban rögzí- 
tettek egyike (universally administered). IP szinten 
az érdekesebb adatok: 


IP: Time to Live -— 1 (0xl) 


Látszik, nem arra tervezték, hogy több hopon átmenjen! Ez egy 
router-router csomag. 


IP: Protocol - Open Shortest Path First IGP 
$ (0x053) 


IP-be ágyazva OSPF utazik. (Mi másra számítottunk?) És most 
jön maga az OSPF rész: 


OSPF: Message - Hello 
OSPF: Version - 2 (0Ox2) 
OSPF: OSPF Packet Type - Hello 
OSPF: Packet Length - 52 (0x34) 
OSPF: Source Router ID - 15b7.254.22b.4bh 
OSPF: Area ID - 0.0.0.0 
OSPF: Authentication Type - Simple Password 
OSPF: Authentication - 0x383735b3534333231 


Itt álljunk meg egy pillanatra. Vissza tudjuk fejteni a jelszót 
(authentication)? Még nem? 


OSPF: Netmask - 255.255.255.0 

OSPF: Hello Interval - 20 (OxA) seconds 

OSPF: Router Priority - 1 (0xl) 

OSPF: Dead Interval - 40 (0Ox28) seconds 

OSPF: Designated Router - L172.15b8.1.13 

OSPF: Backup Designated Router - 1972.1b8.1.14 
OSPF: Neighbor - 20.10.20.10 

OSPF: Neighbor - 30.30.30.30 


A Neighbor mezőkben olvashatjuk, hogy ez az útválasztó milyen 
egyéb útválasztókat talált ezen hálózati szegmensen. A hexa 
panelről ennyit érdemes megfigyelni: 


12345578 


Ez bizony a jelszó. Enyhén clear text. Adapterszinten érdemes 
még megtekinteni a különböző időzítési paramétereket: 





Local Area Connection Properties éz 


General ] NBMA Neighbors . Advanced ] 





IP address: 192.168.1.13 -] ] 
Iransit delay (seconds): eg I 
í 

Retransmit interval (seconds): 5 a ] 
i k ! 
Hello interval (seconds): 10 2 ! 
Dead interval (seconds): fo a ! 
Poll interval (seconds): Aza KR ] 
Maximum transmission unit (MTU) size (bytes): 1500 zi I 


5 Az OSPF időzítésének alapértelmezett értékei. Hello 10 
másodpercenként stb. 


Ezekről annyit érdemes tudni, hogy ha bármelyik útválasztón 


átállítjuk, akkor a többin is után kell húzni! 
Miután a kártyákat felvettük, már zajlik a Link State Table cse- 
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:Svad / 


354TJ UJed 3159340US Uuado 


18 


Open Shortest Path First / 


RRAS : 


rebere. Le is ellenőrizhetjük az RRAS konzollal, va- 
jon látják-e egymást útválasztóink. Az OSPF proto- 
koll jobbgombos menüjében ugyanis a következő ér- 
tékesebb lehetőségek rejlenek: 
Show Link State Database. Itt megtekinthetjük, mit is 
tanult útválasztónk a többiektől. Vigyázat! Itt nem 
konkrét útvonalbejegyzéseket látunk, hanem csak egy 
tájékoztató táblázatot! Ennek minden gépen közösnek 
kell lennie - de az ez alapján generált útvonaltáblák 
" már egyediek! (Lásd később.) 


ACAPULCO - OSPF Link State Database 


T 
9) 


6 





b 





ETTE ZEN ELTETT BNITTETTNTT NETEN 


! 

1 
0.0.0.0 Stub 10.0.0.0 10.10.10.10 431 — 0x00000000 — / 
0.0.0.0 Router 10.10.10.10 10.10.10.10 772 — 0x80000005 ! 
0.0.0.0 Router 30.30.30.30 30.30.30.30 881 — 0x80000006 — / 
0.0.0.0 Router 169.254.126.46 — 169.254.126.46 431 — 0x80000008 — / 
0.0.0.0 Router 169.254.177.213  169.254.177.213 3.4..  0x80000002 I 
0.0.0.0 Network 192.168.1.13 169.254.126.46 431 — 0x8000000€ I 
0.0.0.0 AS External  30.0.0.0 30.30.30.30 750 — 0x80000002 — / 
0.0.0.0 ÁS Extermal  45.45.45.0 30.30.30.30 750 — 0480000002 ! 

! 





o A Link State Table közös minden, azonos areaba tartozó 
routeren. Ez a recept. Ebből főzik az egyedi útvonaltáblákat 


"2 Show Neighbors. Itt tekinthetjük meg, hogy az OSPF Multicast 
címre kibocsátott intenzív hellózás milyen eredményre ve- 
zetett. Találkoztak-e útválasztóink? 






ACAPULCO- OSPE. KET 38 


1821681. 14 
192.168.1.1 









30.30.30.30 ánál Full 
10.10.10.10. Dynamic Full ú o o 








5 ACAPULCO szomszédai 


Nem tudom, megfigyelték-e, de ezidáig az OSPF telepítése is 
éppolyan könnyedén zajlott, mint a RIP-é. Egyszerű hálózatban 
valóban ennyi, de oda a RIP is elég. Ugyanakkor az eddig emlí- 
tett eszközkészlettel (NetMon, Show Neighbors, Show Link State 
Database) felfegyverkezve összetettebb hálózatokon sem kell 
tartanunk attól, hogy az OSPF kicsúszik az ellenőrzésünk alól. 
Sőt! Telepítsd, és felejtsd el! 


A kész útvonaltábla 

Miután gépeink közös nevezőre kerültek a Link State Table kap- 
csán, akkor jön a munka oroszlánrésze: egyedi, az ő nézőpont- 
jukból optimális útvonaltáblát kell generálniuk. Ebbe a folya- 
matba se beavatkozni, se bekukkantani nem tudunk, csak a vég- 
eredmény a mienk. A szokásos route print paranccsal megvizs- 
gálhatjuk, mi született az OSPF áldásos tevékenysége nyomán. 
Nem valami látványos, de azért megmutatom: 


vorkinú vith 


windows / 






BRUTUS ZESZETEŰ 


Hs TCP Logpback interface 
NDIS 5.8 driver 





0 A route print kimenete. Az utolsó, a Metric oszlop alapján 
gyaníthatjuk, hogy melyek a tanult és dinamikusan generált 
béjsüyzések 


Gondok? 

Hogy a problémákról is szó essen: az ICMP Redirect csomagot 
arra találták ki, hogy rossz helyen kopogtató munkaállomások- 
nak a fejébe verje, merre van az arra. Dupla utas (triangle) út- 
választásnál a routerek visszaszólnak a munkaállomásnak, hogy 
legközelebb merre kellene menniük. Ez nagyon jó dolog. A Win- 
dows 2000 gépek hálásan fogadják az ICMP Redirectet. Az RRAS 
is. Bizonyos hálózatokon nemkívánatos, hogy a routerek is be- 
fogadják az ICMP Redirectet: az RRAS is lebeszélhető erről az 
alábbi registry kulcs megfelelő értékével: 


HKEY. LOCAL MACHINENSYSTEMCurrentControlSett 
b ServicestTcpipNParameters 


Itt az EnableICMPRedirect értékét value 0-ra kell állítani. 
További érdekes jelenség állhat elő olyan switchek használata 
esetén, amelyek szigorúan veszik a mulitcast protokollt, de van 
olyan OSPF routerünk is a hálózatban, amelyik nem. (Az RRAS 
komolyan veszi). Ebben az esetben ugyanis az történik, hogy az 
RRAS szabványosan kiküld egy Multicast Join üzenetet, amelyre 
bizonyos routerek nem válaszolnak. Ettől az RRAS nem sértődik 
meg, egyes switchek viszont elzárhatják ezeket a butus 
routereket a rendes, szabványos RRAS elől. 


Fóti Marcell 


marcellfeonetacademia.net 


rab etTTErZI (JG 1 
[1] OSPF Version 2 http://www.ietf.org/rfc/rfc2328.txt 
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A Windows 2000 
és a dinamikus DNS 


Mindenki tudja, hogy a Windows 2000 tartományok elsődleges névfeloldó 
szolgáltatásává (a WINS-et és egyéb NetBIOS varázslásokat végre leváltva) a DNS lépett 
elő. A Windows 2000 munkaállomások a DNS segítségével lépnek be a tartományba, 
jelentkeznek be a hálózatba, veszik fel egymással a kapcsolatot. 


A tartomány DNS zónája ennek megfelelően viszonylag összetett 
és bonyolult, ráadásul a tartalma - főleg dinamikus IP címmel 
ellátott munkaállomások használata esetén - gyakran frissül. 
Az ,ős" DNS-implementációk adatbázisát csakis a zónáért fele- 
lős rendszergazda módosíthatta, frissíthette igény szerint. Egy 
napi haszná- 
latban . lévő 
Windows 
2000 tarto- 
mány DNS zó- 
nájának kar- 
bantartása 
azonban au- 
tomatizálá- 
sért kiált. A Windows 2000 munkaállomások és kiszolgálók 
egyaránt ismerik és használják az RFC 2136-ban [1] definiált di- 
namikus DNS (DDNS) protokollt. 


az , Only secure updates" 
(azaz: , csak biztonságos 
frissítések") lehetőség csak az 
Active Directoryba integrált 
zónák esetén jelenik meg 


DDNS kiszolgáló a Windows 2000-ben 

Kezdjük a kiszolgálóoldallal: a Windows 2000 DNS szolgáltatása 
képes fogadni és feldolgozni a DDNS ügyfelektől érkező névre- 
gisztrációs kéréseket. Ehhez mindössze az adott DNS zóna tulaj- 
donságlapján engedélyeznünk kell a dinamikus frissítést. 
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5 A DNS zónák dinamikus frissítésének engedélyezése. A biz- 
tonságos frissítés csak AD-integrált zóna esetén választható ki 


A kiszolgáló felkészítése a dinamikus üzemmódra mindössze 
ennyiben merül ki. Ami feltűnhet, hogy az ,Only secure 
updates" (azaz: ,, csak biztonságos frissítések") lehetőség csak az 
Active Directoryba integrált zónák esetén jelenik meg. Ennek az 


vörking VIER 
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az oka, hogy a hagyományos, standard elsődleges (Primary) és 
másodlagos (Secondary) zónák ,adatbázisai" egy-egy szöveg- 
fájlban tárolódnak, az AD-integrált zóna adatai pedig a címtár- 
ban található objektumok képében jelennek meg. Míg a 
címtárobjektumokra (akár egyenként, azaz rekordonként is) le- 
het hozzáférési jogosultságokat definiálni, egy szövegfájl sorai- 
ra már nehézkesen. Ez látható abból is, hogy a nem AD-integrált 
zónák rekordjainak tulajdonságlapjáról hiányzik a , Security" ol- 
dal. A címtárintegrált zónánk objektumait egyébként megtalál- 
juk az Active Directory Users and Computers eszközben is, ha a 
View menüben kiválasztjuk az Advanced Features opciót. 
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0 Az AD-integrált zónában található rekordok hozzáférési 
jogosultságait definiáló oldal a DNS Manager-ben... 
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a A hozzáférési jogosultságok alapértelmezését külö- 


nösebb ok nélkül nem érdemes módosítani, de ha 
szükség van rá, bátran megtehetjük. A biztonságos 


Pss használt DDNS protokollt és eljárást 


később ismertetjük. 


Dinamikus DNS-frissítés 

Térjünk át ügyféloldalra. (Figyelem! DDNS regisztrációt nemcsak 
a munkaállomások, hanem a kiszolgálók is végeznek, ezért a 
nDDNS ügyfél" kifejezést a későbbiekben egyaránt érthetjük mind 
a Professional, mind a Server operációs rendszerekre. ) 


A Windows 2000 munkaállomások és kiszolgálók címre- 
gisztrációját a DHCP Client Service (DHCP ügyfél) végzi - 
függetlenül attól, hogy statikus, vagy dinamikus (DHCP ki- 
szolgálótól kapott) IP címet használ a számítógép! 


A aímregisztráció alapértelmezésben minden 24 órányi folyamatos 
működés után, illetve az alábbi események bekövetkeztekor zajlik le: 
"0 Megváltozik a TCP/IP beállítás, a számítógép új IP címet kezd 
el használni, vagy megválik egy régitől 

Lejár a DHCP-től kapott IP cím bérleti ideje, illetve a munka- 
állomás frissíti a kapott címet 

0 Plug-and-Play esemény után 

A regisztrációt két módon , kézzel" is kiválthatjuk. Az első az 
ipconfig parancs új kapcsolója: 


ipconfig /registerdns 


é § másik HEGt a Héllagok szúlgáltatás újraindítása His ugya- 


net stop netlogon 
net start netlogon 


A Windows 2000 nem csak akkor próbálkozik meg a regisztrációjá- 
val, amikor tartományba léptetjük. Ha a rendszer tulajdonságlap- 
ján a számítógép neve mellett kitöltjük az elsődleges DNS utótag 
értékét (Primary DNS suffix), a regisztráció működni fog az így 
képzett számítógépnévvel, tartományon kívül is. (Ha ez a mező 
nincs kitöltve, nincs mit bejegyezni - ergo a regisztráció is elmarad.) 


2121 





General . Network Identification ] énse] ú User ZSZ Advanced] 
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ag Windows me 8 
onthene You can change the name and the membership of this 
computer. Changes may alfect access to nelwotk resources. 
Full computer name: 


ezen Computer name: 


To use the Network. [V2kpro 


domain and create z Full ; 


s w2kpro.falatrax.hu 
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Primary DNS sutfix of this computer: 


ffalatrax hd 


[7 Change primary DNS suffix when domain membership changes 


NetBIOS computer name: 
W2KPRO 


This name is used for interoperabikíty with older computers and services. 


ET] em 








o A számítógép teljes nevét a számítógépnév és az elsődleges 
DNS utótag összevonásával generáljuk — tartományon kívül is! 
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Példánkban a számítógép teljes neve tehát: , w2kpro.falatrax.hu". 
Az elsődleges utótag a gép tartományba léptetésekor megváltozhat. 


A dinamikus regisztráció protokollja 

Kicsit kénytelenek vagyunk elmélyedni a DDNS protokoll szabvá- 
nyába (RFC 2136, [1]). A [2] címről letölthető néhány, Network 
Monitorral elfogott regisztrációs forgalom. Az alábbiakban leírtak 
jól követhetők a nem tartományi tag Windows 2000 Professional 
által generált forgalmon, amit a pro. workgroup start dnsdyn.cap 
fájlban találunk. A DDNS frissítés igazodik a megszokott DNS proto- 
kollhoz, némileg kibővítve azt. Hálózati forgalom szempontjából elég 
azt tudnunk, hogy a DDNS forgalom az UDP 53-as, vagy szükség ese- 
tén a TCP 53-as porton zajlik. Maga a dinamikus DNS csomag két leg- 
fontosabb része az úgynevezett előfeltételek és a frissítendő adatok. 
A prerekvizíciós rész olyan előfeltételeket tartalmaz, amelyeknek 
teljesülniük kell ahhoz, hogy a kívánt rekord bejegyzésre kerülhes- 
sen. Ilyen feltétel lehet például, hogy egy adott nevű A vagy 
CNAME rekord már legyen a zónában, vagy pedig éppen ellenkező- 
leg: ne létezzen. A prerekvizítumok teljes listáját a [3] címen fog- 
laltuk össze, de természetesen az RFC-ben is utána lehet nézni. 










mDNS: Prereguisíte: w2kp: 
mDNS: Rescurce Re 
DNS: Resource Name 
DNS: Rescurce Type 
DNS: 
DNS. 
DNS: 
DNS: Rescurce Re 
DNS: Resource Ni 
DNS: Rescurce Type 
DNS: Rescurce Class z Ox0 
DNS: Tíze To Líve z 0 (020) 
DNS: Rescurce Data Length z 0 (00) 


latrax.hu. cf type Canonical name en class 
zax.hu. of type Canonical name en c: 
Tax.hu. 

ame for alias 














0x0) 
x.hu. ef type Host Addr on class 











9 Prerekvizítumok listája egy regisztrációhoz 


A fenti példában például két feltételt látunk: 

2 w2kpro.falatrax.hu nevű, CNAME típusú rekord nem létezhet 
(RRset Does Not Exist) 

2 we2kpro.falatrax.hu nevű A típusú rekord nem létezhet (RRset 
Does Not Exist) 

Azaz, a bejegyezni kívánt cím se alias, se közvetlen hivatkozás 

formájában ! ne szerepeljen a zónában - érthető feltétel egy új 

















5 Regisztrációs adatok az Update mezőben 


Az Update mező is tartalmazhat egynél több rekordot; a fenti 
például egy új bejegyzést hozna létre a zónában. Emellett re- 
kordok törlésére is lehetőség van: ilyenkor az Update mezőben 
megjelenik a törölni kívánt rekord, 0-s TTL értékkel (lásd pél- 
dául az IP cím változtatáskor lezajlott forgalmat bemutató 
pro domain ipchange dnsdyn.cap fájlt). Ha a feltételek nem 
teljesülnek, a regisztráció nem megy végbe, mi pedig a kiszol- 
gáló által visszaküldött válaszból értesülünk a tényről. Az aláb- 
bi ábra egy sikeres műveletet mutat: 


HÚS: BA: 









t authority for dozain 
cemplere 
desired 


NET adár. 
cal nam elass 


ET adár. 











a A bejegyzés sikerességéről a kiszolgáló válaszában az 
RCode mezőben tájékoztat minket. 


A hibakódok teljes listája az RFC-ben található, de a Network 
Monitor is visszafejti nekünk, amit látni szeretnénk. Érdekesség, 
hogy ,tapogatózási" célból olyan DDNS kérést is küldhetünk, 
ami Update mezőt nem, csak előfeltételeket tartalmaz. Ilyenkor 
a kiszolgáló válaszából lehet következtetni a zóna tartalmára 
(vagy akár arra, hogy a kiszolgáló támogatja-e a DDNS kommuni- 
kációt). Ennyit az általános regisztrációs forgalomról, most pe- 
dig következzen a Windows 2000-féle, gyakorlati megvalósítás. 


Dinamikus DNS bejegyzés a" la Windows 2000 

Amikor a Windows 2000 dinamikus DNS bejegyzésre készül, az 

alábbiakat teszi (ha van lehetőségünk, Network Monitorral követ- 

hetjük a leírtakat a pro workgroup start dnsdyn.cap fájlban; a 

sorok elején látható számok a frame-ek sorszámát jelölik) : 

0 H6: A Windows a beállított DNS kiszolgálótól lekérdezi a saját 
nevéhez (w2kpro.falatrax.hu) tartozó SOA rekordot (ami egy- 
ben a szülőtartomány SOA rekordja is). Erre azért van szükség, 
mert a dinamikus regisztrációs kéréseket a zóna hiteles (au- 
thoritative) példányát tartalmazó kiszolgálóhoz kell küldeni. 

0 H7:a helyi DNS kiszolgálótól visszaérkező válaszban (a SOA 
rekordban) többek között megtalálható a zóna elsődleges 
névkiszolgálójának neve és IP címe egyaránt (server. falat- 
rax.hu, 192.168.77.2). 

0 8: a kliens egy frissítés nélküli (!) DDNS kérést küld a ki- 
szolgálónak, amiben az alábbi két feltétel szerepel: 

1. —— Ne létezzen w2kpro.falatrax.hu alias (CNAME) bejegyzés 

2. —— Létezzen w2kpro.falatrax.hu host (A) bejegyzés, még- 
pedig a 192.168.77.111 IP címmel (ez a kliens jelen- 
legi IP címe) 

Gondoljunk csak ebbe bele! Ha létezik a számítógép nevével 

megegyező alias (CNAME) a zónában, az eleve kellemetlen (akkor 

nem hozhatunk létre A rekordot a nevére, előtte a meglévő aljast 
törölni kell), tehát az első kérdés jogos. A második kérdés pedig 
arra ad választ, hogy a név, mint host (A) rekord regisztrálva van- 

e, és ha igen, akkor az IP címe megfelelő-e. Ha a kiszolgáló most 

pozitív választ ad, nincs szükség regisztrációra, hiszen pontosan 

a megfelelő adatok vannak a zónában. Ha a második feltétel nem 

megfelelő, akkor belekezdhetünk az adatok frissítésébe. Végül pe- 

dig, ha a kiszolgáló abszolút elutasító választ ad (, not supported"), 

a zóna dinamikus frissítéséről is le kell mondanunk. 

I H9: esetünkben a kiszolgáló hibaüzenete jelzi, hogy a bejegy- 
zés még nem létezik, ezért következhet a dinamikus regisztráció 

0 H12: A következő DDNS kérés már előfeltételeket és Update 
adatokat is tartalmaz. A feltételek - az előző válaszhoz iga- 
zodva - az alábbiak: 

1. Ne létezzen a w2kpro.falatrax.hu alias (CNAME) rekord 
2. —— Ne létezzen a w2kpro.falatrax.hu host (A) rekord 
Az Update szakaszban pedig megjelenik a bejegyzendő név és IP cím. 
0 H13: a kiszolgáló válaszában jelzi a sikeres regisztrációt 
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Ha az első kérdésre adott válaszban az derül ki, hg" 
hogy a cím már létezik, csak helytelen IP címmel, hú 


akkor a frissítő csomagban a regisztráció mellett ta- 

lálnánk egy, a régi rekordot törlő bejegyzést is (em- 

lékszünk, 0-s TTL értékkel); valamint a prerekvizítumok is 
ennek megfelelően alakulnának. Az újonnan bejegyzésre kerülő 
rekordok TTL értéke (mint láthatjuk) 1200, azaz húsz perc. Ezt 
az alapértelmezést megváltoztathatjuk, ha a registryben módo- 
sítjuk az alábbi (REG DWORD) értéket: 


HKEY LOCAL MACHINENSYSTEMNCurrentControlSetV 
SericesXTcpipNParametersWDefaultRegistrationTTL 


A Windows 2000 ezután megpróbálkozik a reverse DNS cím (PTR 
rekord) bejegyzésével is, ami a mi minta-alhálózatunkon a 
reverse zóna hiányában nem sikerül. 


A Windows 2000 DHCP Server 

Statikus IP címet használva a Windows 2000 tehát mind a saját 
A, mind a reverse (PTR) rekordját automatikusan regisztrálja. 
Ha az IP címét dinamikusan, (Windows 2000) DHCP kiszolgáló- 
tól kapja, akkor a DHCP címkiosztási folyamat során megálla- 
podnak abban, hogy melyik adatot ki fogja bejegyezni. Az alap- 
értelmezés ilyenkor az, hogy az A rekordot a kliens, a PTR rekor- 
dot a szerver regisztrálja. Ha a kiszolgáló válaszában nem jelzi, 
hogy képes lenne a regisztrációra (például, mert régebbi DHCP 
kiszolgálóval állunk szemben) , akkor a teljes regisztrációt elvég- 
zi a kliens. A Windows 2000 DHCP Server szolgáltatása azonban 
képes a teljes regisztrációs folyamatot is magára vállalni, így a 
dinamikus DNS áldásos szolgáltatásait akár a Windows 
95/98/Me/NT számítógépek is élvezhetik, ha az IP címüket egy 
Windows 2000 DHCP kiszolgálótól kapják. 






[atom ven [d 516 
Tree l 


— General DNS [Advanced] 


"You can set up the DHCP server to automaticaly update name and address 
formation On ONS servers that support dynamic updatez. 


(7. Automatcaly update DHCP cbent intormation ín DNS. 






server falatrax.hu [192.168.77.2] 
5 (I $ccpe[192.168.77.0) Falatrax 


(DJ Address Pool G Update DNS only DHOP cfent regvests 
DJ Address leases 
9 CB Reservations C Always update DNS 
veve elt F7. Discard forward (name tosddtess) lookups when lease exptez 
0 Server Ogtians 
A FESS szöttkt DÍS EHEN SS Et essek Örös RIES 
Updates are sent to DNS serverz configured in TCPAP properties for 
network connections acíve at this server. 











5 A DHCP kiszolgáló DNS-beállításai 


A DHCP kiszolgáló tulajdonságlapjának DNS oldalán az alábbi 

beállítási lehetőségeket találjuk: 

2 Automatically update DHCP client information in DNS - a DHCP 
ügyféladatok automatikus frissítése a DNS-ben, mégpedig: 

"2 Update DNS only if DHCP client reguests - frissítés csak akkor, 
ha a DHCP kliens ezt kéri (lásd fenn) 

6 Always update DNS - frissítés minden esetben 

"2 Discard forward (name-to-address) lookups when lease expires 
- ha ezt engedélyezzük, a DHCP kiszolgáló a bérleti idő le- 
jártakor a DNS-ből törli az adott IP címet (akkor is, ha azt 
nem ő regisztrálta be!) 

"B Enable updates for DNS clients that do not support dynamic 
update - frissítés engedélyezése a DDNS-t nem ismerő klien- 
sek nevében 
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RAS-ügyfelek IP-cím regisztrációja 
A Windows 2000 RAS-ügyfelek betárcsázáskor regiszt- 
rálják mind az A, mind a PTR rekordokat. A vonal bon- 
tásakor megkísérlik a regisztrációk törlését is (!), bár, 
ha a kérésre négy másodpercen belül nem érkezik válasz, 
bontják a vonalat (és a tényről bejegyzés készül az Eseménynapló- 
ba is). Az ügyfél kijelentkezésekor egyébként az RRAS kiszolgáló 
szolgáltatás is megpróbálkozik a PTR rekord deregisztrációjával. 


Több hálókártya, több DNS kiszolgáló, egyedi DNS-utótagok 
Ha a számítógépben több hálókártya található, a Windows min- 
den hálózati csatoló elsődleges IP címét jegyzi be. Ha ezt nem 
szeretnénk, a regisztrálni nem kívánt hálózati csatoló TCP/IP 
protokolljának Advanced tulajdonságlapján, a DNS oldalon kap- 
csoljuk ki a ,Register this connectior"s addresses in DNS" opciót. 


DNS sulfi for this connection: intranet. falatrax.hy 


[7 Register this connectionis addresses in DNS 
FT Use this connectionts DNS suffix in DNS registration 





Cancel 


5 További beállítások a hálózati csatolók TCP/IP protokolljánál 


Ha a csatolókon különböző DNS kiszolgáló- 
kat definiáltunk (például a belső hálókár- 
tyára a belső; az Internet felé néző hálókár- 
tyán pedig az Internet-szolgáltató DNS ki- 
szolgálóját), akkor a Windows mindegyik 
DNS kiszolgáló felé csak az adott ,irány- 
ból" elérhető IP címeket fogja regisztrálni. 
Ha valamelyik hálózati csatolón egyedi 
DNS utótagot definiálunk, és engedélyez- 
zük az ábrán kurzorral jelölt , Use this con- 
nections DNS suffix in DNS registration" opciót, akkor a Win- 
dows az itt megadott DNS utótagból képzett számítógépnevet is 
megkísérli majd regisztrálni. 


A végére egy kis desszert... 

Az automatikus DNS regisztrációt (az A és PTR rekordok bejegy- 
zését egyaránt) az operációs rendszer szintjén letilthatjuk, ha 1- 
re állítjuk az alábbi (REG DWORD) registry-értéket: 


Ha a számítógépben 
több hálókártya 
található, a Windows 
minden hálózati csatoló 
elsődleges IP címét 
jegyzi be. 


HKEY LOCAL MACHINENSYSTEMNCurrentControlSett 
ServicesXTcpipMParametersDisableDynamicUpdate - 1 


érték neve legyen ,DisableReverseAddressRegistration". Ha a 
fenti értéket nem a globális TCP/IP paraméterek között, hanem 
egy hálózati csatoló kulcsa alatt hozzuk létre, akkor a dinami- 
kus regisztrációt csak az adott csatolóra tiltjuk le, például: 


HKEY. LOCAL MACHINENSYSTEM CurrentControlSett 
ServicestTtcpipNParametersUilnterfacest 

( FD3ABAAL-CSFB-4E74-ABEE-9BCF352BS34EJN 
DisableDynamicUpdate - 1 


További információkat a 0246804 tudásbázis-cikkben találunk [4]. 
A Windows 2000 Server-en Service Pack 1 előtt az SRV rekordok 
a fenti (és akár kártyánkénti) beállítástól függetlenül is bejegy- 
zésre kerültek; SP1 óta a dinamikus regisztráció tiltása érvényes 
az SRV rekordokra is [5]. 

A Windows 2000 Server és Advanced Server üzemeltetői talán ész- 
revették már, és nyilván nagyon csodálkoztak, hogy hiába tiltották 
egy-egy hálózati csatoló IP címének regisztrációját a kártya tulaj- 
donságlapján, a Windows a következő alkalommal hajlamos volt a 
ntiltott" címet is bejegyezni a DNS-be. Ennek egyik oka lehet, ha a 
kiszolgálón fut a DNS szolgáltatás, ez 
ugyanis minden IP címet, amin keresz- 
tül elérhető, bejegyez az adatbázisba, 
függetlenül a hálózati csatolón találha- 
tó beállítástól. Ha ezt szeretnénk elke- 
rülni, hozzuk létre az alábbi registry-ér- 
téket (típusa: REG SZ): 


HKEY. LOCAL MACHINENSYSTEMNCurrentControlSetYV 
ServicesXDNSNParameterstPublishAddresses 


Ide, szóközzel elválasztva felvehetjük a regisztrálni kívánt IP cí- 
meket - ha az értéket üresen hagyjuk, a DNS Server szolgálta- 
tás a kiszolgáló összes IP címét regisztrálni fogja [6]. 


folytatjuk... 


Fülöp Miklós 
mick Onetacademia.net 


A cikkben szereplő URL-ek: 


[1] http://www.ietf.org/rfc/rfc2136.txt 

[2] http://technet.netacademia.net/download/ddns/ 

[3] http://technet.netacademia.net/download/ddns/ddns-prereg.txt 
[4] http://support.microsoft.com/default.aspx?scid-kb;en-us:0246804 
[5] http://support.microsoft.com/default.aspx?scid-kb;en-us:0280439 
[6] http://support.microsoft.com/default.aspx?scid-kb;en-us;0275554 
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Ki mivel 
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Az életmentő LDAP 


Januárban indítottuk útjára ,Ki mivel §?" rovatunkat, melyben időről időre 
beszámolunk egy-egy kacifántos, esetleg rejtélyes , ügy" megoldásáról. 

Ez a rovat nyitott: ha valaki munkája során olyan kíntapasztalatra tesz szert, 
mellyel mások szenvedését enyhítheti, kérem írjon nekünk a 


cikktipp(onetacademia.net címre! 


A csatamezőn szerzett sebesülés még akkor sem szégyen, ha a 
hátunkba kapjuk, mert mire katonatörténet kerekedik belőle, a 
kínos részletek a feledés homályába merülnek..." 

(Svejk) 


I. felvonás 

Történt egyszer, hogy X vállalatnál felmerült az igény, hogy egy 
gyalogos, mezei felhasználó bejelentkezési jogot kapjon a tarto- 
mányvezérlőkön. Mint az közismert, Active Directory esetén a 
rendszerszintű jogosultságokat (Log On Locally, Change the System 
Time stb.) csoportos házirenddel (group policy) lehet kiosztani. A 
házirendet ez esetben mindig arra a szervezeti egységre kell illesz- 
teni, amelyikben az érintett számítógép fiókja található. Ha a tar- 
tományvezérlő jogviszonyait kívánjuk módosítani, a Domain Cont- 
rollers szervezeti egység házirendjét illik átállítani. 

Illik, de nem muszáj! A házirendbeállítások öröklődése miatt ugyan- 
is nemcsak az adott tárolón, hanem a felette lévő szinteken vég- 
hezvitt módosítások is érvényre jutnak. Az alábbi ábrán tehát 
mind a Domain Controllers, mind pedig a tartomány gyökere alkal- 
mas célpont a Log On Locally jog kiosztására. Melyiket válasszam? 


Fe sJ Ae (easjektoga 
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Active Directory Users and active Directory Use 
a-CI Saved Gueries 


E eg netacademia.frn 
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5 Hová tegyük a csoportos házirendet? Ezt mindig a feladat 
határozza meg. 


- Ha magasabb ponton adagolom a jogot, messzebbre jut - gon- 
dolta a rendszergazda. Ebben tökéletesen igaza van. Kitt-katt, 
és a tartomány gyökerébe az alább látható módon felvette Júzer 
Jolánt a helyi bejelentkezésre jogosult felhasználók (egyébként 
üres) listájába. Ám hiába állította be megfelelően a kívánatos 
jogosultságot, az csak nem akart érvényre jutni. 
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File Action View Help 
$€-7 Elm. €eBEÉ 
(eZT Defaukt Domain Policy (platan.netac 


— 9 computer Configuration 
CI Software Settings 
z (CI Windovis Settings 
ÉJ Saipts (Startup/shutdo 
Security Settings 
4 EA Account Policies 
— £gj Local Policies 
4 A Audit Policy 
7 dgj User Rights Az 
4 ég) Security Option 
4 Éj Event log 
4 a Restricted Groups 








8) Log on locally 
té 


Define these policy seltingsi 
pén Júzer 








ILock pages ín memori 


a Helyi bejelentkezési jogot adunk Júzer Jolánnak a tartomány 
gyökerén. Hogy mi lesz ebből...! 


Várt-várt, majd az alábbi házirendfrissítési cselhez folyamodott: 
secedit /refreshpolicy machine policy 


A fenti parancsnak a tudomány mai állása szerint soron kívül ki kel- 
lett volna értékelnie a házirend változásait - ám a jogváltozás to- 
vábbra sem lépett érvényre. Hősünk ekkor elkeseredett lépésre 
szánta magát: elővett egy könyvet, hogy utánanézzen a , hibának". 
A szakirodalom szerint kétféle házirendbeállítás létezik: az 
egyik típus összeadódik a hierarchia más pontjain található 
testvérkéivel (ilyen például a szoftvertelepítés), a másik pedig 
felülírja szülei ellentétes utasításait (például így működnek a re- 
gistrymódosító parancsok). Mivel hibajelzést a rendszer nem 
adott, kézenfekvő, hogy a rendszerszintű jogokat a második 
csoportba kell sorolni, vagyis a gyermek felülbírálja a szülőt. Ez 
valóban így igaz: a Domain Controllers tárolón beállított jogok 
miatt a fentről jövő jogáldás nem érhette el célját. Ebből a ku- 
tyaszorító helyzetből két módon is ki lehet evickélni: 

"0 vagy megalkuszunk, és áttesszük az erősebb (tehát a gyer- 

mek-) házirendbe a kívánatos módosítást 
- vagy beavatkozunk a házirendöröklődés szokásos menetébe, 
és megemeljük a szülőnek beadagolt szabály prioritását 

Hősünk nem egy megalkuvó tipus, így a második megoldás mel- 
lett döntött. No Override! Senki ne eressze el a füle mellett az 
én parancsomat! Ez a házirendbeállításoknál itt található 
(Group Pilicy, Options gomb): 
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Disabled: the Group Policy Object is not applied to this 
container 


5 A magasabb szinten elhelyezett házirend felülírhatósága 
megszüntethető a No Override pipával 





A fenti policyfrissítési parancs után Júzer Jolán végre be tud je- 
lentkezni a tartományvezérlőkre. Csak éppen senki más nem! 


II. felvonás 

Helyzet: az egyetlen ,normális" felhasználó a tartományban 
Júzer Jolán! 

Hősünk hamarosan észreveszi a malőrt, és szokásához híven kap- 
kod fűhöz, fához, szalad a vargához... Miután ezzel végzett, elkezd 
gondolkodni: vissza kellene venni a policyról a No Override jelzést. 
Sajnos ahhoz Jolánnak nincs megfelelő jogosultsága. Sebaj, a Run 
As szolgáltatást pont az ilyen helyzetekre találták ki nemde? No- 
sza, Jolán bejelentkezéséből futtassuk az Active Directory Users 
and Computers eszközt! Futás helyett azonban ezt kapjuk: 


AN Nase e 


€2 C:ÁWINDOWSIsystem32iwinmine. exe 


Logon failure: the user has not been granted the reguested logon type at this 
computer, 





a Ha már a Minesweeper elindításához sincs elegenő joga 
az Administratornak, akkor komoly baj van! 


Ez baj. Komoly baj. Más eszköz nem ismert a házirend módosítá- 
sára, ADSI Edittel meg azért mégse. Milyen , szerencse", hogy az 
sem indul! A policy közvetlen visszaállítása tehát - eszköz híján - 
kiesett a megoldási lehetőségek közül. Vagy esetleg egy másik 
gépen bejelentkezve, távolról futtatva? És ekkor jön a sokk: a vál- 
lalat összes gépéről kitiltódott mindenki! (Nyilván. Hisz a tar- 
tomány gyökerétől erőszakkal végigörököltetett Log On Locally beál- 
lítás a munkaállomásokra is lecsorgott!) Most mi lesz? 
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III. felvonás 

Úgy látszik, nincs más megoldás: meg kellene ,hekkelni" a tar- 
tományt, hogy egyetlen felhasználónk, Júzer Jolán rendsz- 
ergazdai jogkörbe kerüljön, és képes legyen visszavenni a házi- 
rend erősségéből. Azonban az Active Directoryt nem olyan puha 
anyagból gyúrták, hogy csak úgy mindenféle nyomásnak enged- 
jen. Elevating privileges? Ilyen biztonsági lyuk nincs benne. 
Használjuk fel azt a tényt, hogy ismerjük a rendszergazda nevét 
és jelszavát. Igaz ugyan, hogy egyetlen gépen sem tud bejelent- 
kezni, de távolról, más tartományból, vagy más operációs rend- 
szerről a névájelszó egyezés miatt mégiscsak jutna valamire. 
Más tartomány nincs kéznél, s telepíteni is időigényes lenne. 
Más operációs rendszer sincs, de van valami, amivel az idegen- 
ség látszatát lehetne kelteni, s így be lehetne csapni a 
Windowst: dehogyis akar helyileg bejelentkezni az Administ- 
rator! Csakis távolról! Az LDAP protokoll, még pontosabban a 
címtár exportálása-importálása (LDIFDE segítségével) segít ne- 
künk a cselezésben. Tavaly májusi számunkban olvasható az 
LDIF fájlok használatának részletes leírása, itt most csak az el- 
vet és a megoldást közlöm. 

Célunk: a kiütött rendszergazda segítségével ,helyzetbe hozni" 
Jolán felhasználói fiókját, hogy engedelmeskedjenek neki a 
rendszergazdai eszközök. Ehhez egy olyan LDIF fájlt készítünk 
(modosit.txt), mely Jolánt beemeli a Domain Admins csoportba: 


DN: CN-Domain Admins,CN-Users,DC-falatrax,DC-hu 
changetype: modify 

add: member 

member: CN-Juzer Jolan,CN-Users,DCsfalatrax,DC-hu 


Ezt a fájlt az alábbi paranccsal importálhatjuk be az Active 
Directoryba (ahol -i az import üzemmódot, -f a beemelendő fájlt, 
-b pedig a felhasználó azonosítási adatait állítja be): 


LDIFDE -i -f modosit.txt -b Administrator falatrax 
4 


Maga az import tehát az eredeti Administrator erősségével fut. Az 
LDIFDE szerencsére nem kér interaktív bejelentkezést az operációs 
rendszertől, így akadálytalanul beemeli a címtárba ravasz módon 
megfogalmazott importfájlunkat. Jolán Domain Adminná vált. Gyors 
kijelentkezés-bejelentkezés után (hogy a csoporttagság-változás ér- 
vényre jusson), máris rendet lehet tenni a szétesett címtárban. 
Ezúttal: Happy End. 


Fóti Marcell 
MCSE 
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Mikor és miért felel az 
Internet szolgáltató? 


A 2001. évi CVII. törvény legfontosabb előremutató rendelkezése 
a szolgáltatói felelősség szabályozása. A kérdés alapvetően természetesen az, 
hogy a hálóra felkerült tartalomért a szolgáltatást nyújtók mely csoportja, 


és milyen mértékű felelősséggel tartozik. 


A jogalkotó mindenekelőtt kimondja, hogy a szolgáltató (eza- 
latt bármely típusú szolgáltatás nyújtóját értve) a polgári jog ál- 
talános szabályai szerint felel az információs társadalommal 
összefüggő szolgáltatás során továbbított, tárolt vagy hozzáfér- 
hetővé tett, jogszabályba ütköző tartalmú információval oko- 
zott jogsérelemért, illetve kárért. Ezt követően kerül sor a fele- 
lősség alóli mentesülés eseteinek meghatározására. 

A polgári jog általános szabályai szerinti felelősség megállapí- 
tásához szükséges, hogy az adott magatartás jogellenes és fel- 
róható legyen. A jogellenesség ténylegesen azt jelenti, hogy a 
magatartás (vagy mulasztás) valamely jogszabályba ütközzön, 
jogszabály által biztosított vagy védett jogot sértsen, vagy kö- 
telezettségnek ne tegyen eleget. A felróhatóság viszont a Pol- 
gári Törvénykönyvben úgy kerül meghatározásra, hogy a károko- 
zó számára mentesülést jelenthet, ha magatartása nem volt fel- 
róható. Vagyis alapvetően feltételezi a jogalkotó, hogy a jogel- 
lenes magatartás egyben felróható is, de lehetőséget ad a kár- 
okozó számára, hogy bizonyítsa, hogy az adott helyzetben úgy 
járt el, ahogy az az adott helyzetben általában elvárható volt. A 
bizonyítás kötelezettsége tehát a szolgáltatóé, és nem azé, aki 
kártérítési igényt kíván érvényesíteni. Kérdés - és itt kapott ko- 
rábban nagy teret a bírói gyakorlat - hogy egy Internet szolgál- 
tató esetében, ha mondjuk több tízezer oldal tárhelyet biztosít, 
mi az elvárható magatartás a jogellenes tartalmú információk 
közzétételének megakadályozására? Elvárható-e, hogy naponta, 
vagy annál gyakrabban ellenőrizze a több tízezer oldalon, hogy 
vajon felkerült-e jogsértő tartalom oda vagy sem? Egy vitafórum 
működtetése esetében milyen mértékű moderálás várható el? Az 
ilyen, és ehhez hasonló kérdésekre részben választ ad a törvény, 
amikor a mentesülés eseteit határozza meg. 

A szolgáltatónak egy adott jogsértő tartalomért való felelősség 
alóli mentesüléshez egyszerre két kérdésnek kell megfelelnie: 
tartózkodjon a törvényben konkrétan meghatározott formájú, 
aktív közreműködést megvalósító magatartástól, továbbá te- 
gyen eleget a notice and take down eljárás megindítása esetén 
az ebből eredő kötelezettségeinek. 

A továbbiakban a törvény valamennyi szolgáltató vonatkozásá- 
ban kimondja, hogy nem köteles előzetesen és rendszeresen el- 
lenőrizni az általa csak továbbított, tárolt, hozzáférhetővé tett 
információ tartalmát, továbbá nem köteles olyan tényeket vagy 
körülményeket keresni, amelyek jogellenes tevékenység folyta- 
tására utalnak. Ezt követően kerül sor az egyes szolgáltatások- 
hoz fűződő magatartások meghatározására. 

A távközlő hálózaton történő adattovábbítás, vagy a távközlő 
hálózathoz való hozzáférés biztosítása (egyszerű adatátvitel) 
esetén a szolgáltató akkor nem felel, ha nem maga kezdeménye- 
zi az információ továbbítását, nem maga választja meg a cím- 
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zettet, nem maga választja ki az információt, illetve azt nem 
változtatja meg. Az egyszerű adatátvitel fogalmába tartozónak 
érti a törvény az információ közbenső és átmeneti jellegű auto- 
matikus tárolását is, amennyiben ennek célja kizárólag az infor- 
mációtovábbítás lebonyolítása, és nem tart hosszabb ideig, 
mint ami a továbbításhoz szükséges. 
Az a szolgáltató, aki az információt a távközlő hálózaton továb- 
bítja és ezzel alapvetően a mások által kezdeményezett informá- 
ciótovábbítást teszi hatékonyabbá, az információ közbenső és 
automatikus tárolása esetén akkor nem felel, ha 
-0 nem változtatja meg az információt, az információhoz való 
hozzáférést a megfelelő feltételek szerint biztosítja, 
-? a közbenső tárolóban az információ frissítése megfelel a szé- 
les körűen elismert, és alkalmazott információfrissítési gya- 
korlatnak, 
a közbenső tárolás nem zavarja meg az információ felhasz- 
nálásával kapcsolatos adatok kinyerésére szolgáló, széles körűen 
elismert és alkalmazott technológia jogszerű használatát, és 
0 a szolgáltató haladéktalanul eltávolítja az általa tárolt infor- 
mációt vagy nem biztosítja az ahhoz való hozzáférést, amint 
tudomást szerez arról, hogy az információt az adatátvitel 
eredeti kiindulási pontján a hálózatról eltávolították, vagy 
az ahhoz való hozzáférés biztosítását megszüntették, illet- 
ve hogy a bíróság vagy más hatóság az eltávolítást vagy a 
hozzáférés megtiltását rendelte el. 
A tárhelyet biztosító szolgáltató akkor mentesül a kártérítési fe- 
lelősség alól, ha nincs tudomása arról, hogy a tárolt információ 
jogellenes, vagy bárkinek jogát, jogos érdekét sérti, illetve, 
amint erről tudomást szerez, haladéktalanul intézkedik az infor- 
máció eltávolításáról. 
Ez utóbbi rendelkezés némi aggodalomra adhat okot, hiszen nyi- 
tott kérdés, hogy a tudomást szerzés mivel merül ki? Tudomást 
szerez-e a szolgáltató, ha valaki vélt vagy valós jogsértésről tájé- 
koztatja? Jogosult-e a szolgáltató ez esetben haladéktalanul eltá- 
volítani az információt, vagy meg kell várnia, amíg a jogellenes- 
séget valamilyen bírói vagy más határozat jogerősen kimondja? 
Az említett aggályt leszámítva a szolgáltatók mentesülési ese- 
tei logikusan, egymásra épülve kerültek meghatározásra, és el- 
fogadható a valamennyi közös alapelveként szolgáló gondolat, 
hogy a szolgáltató nem felel azért, amiről nincs tudomása. Bár- 
mily egyértelműnek tűnik is ma már ez a meghatározás, koráb- 
ban számos olyan bírói döntés volt mind az amerikai, mind az 
európai jogesetek körében, amely ezzel ellentétesen, megállapí- 
totta a , vétlen" szolgáltató felelősségét is azért a tartalomért, 
amelyről nyilvánvalóan nem lehetett tudomása. Így ítélt el a 
svájci bíróság egy Internet szolgáltatással, tárhely biztosítással 
foglalkozó egyetemistát, aki a több tízezer oldal közül nem 
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szűrte ki és nem távolította el az ott elhelyezett 
jogellenes, esetünkben történetesen éppen pornog- 
ráf tartalmú információt. 


A törvény alapjául szolgáló Irányelve az Európai Uniónak 
nem rendelkezik a keresőszolgáltatást működtető Internet szol- 
gáltatók felelősségéről. A magyar jogalkotók azonban erre is ki- 
terjesztették a normatív jogalkotást, így a Yahoo eset tanulsá- 
gait leszűrve a szolgáltatót mentesíti a törvény a kereséssel fel- 
lelhető információk esetleges jogellenessége miatti felelősség 
alól, ha a szolgáltatónak nincs tudomása az információ jogelle- 
nességéről, vagy nincs tudomása olyan tényről vagy körülmény- 
ről, amely valószínűsítené (!), hogy az információval kapcsola- 
tos magatartás jogellenes vagy arról, hogy az információ bárki- 
nek jogát vagy jogos érdekét sérti. Itt ismét a régi dilemma kö- 
szönt ránk vissza: vajon ha a keresőszolgáltatást fenntartónak 
van tudomása olyan tényről, amely szerint esetleg az adott in- 
formáció jogellenessége valószínűsíthető, akkor már felelősség- 
re vonható azért, mert elősegíti az információ megtalálását? Ha 
jól belegondolunk, olyan mértékű gondosságot követel meg ez 
a szabály a szolgáltatótól, amely ellentétes a polgári jogban 
használatos , általában elvárható" magatartás mércéjével. A jog- 
ellenesség valószínűsége olyan megfoghatatlan, annyira az ügy- 
ben majd eljáró bíró személyiségétől és más körülményektől 
függő mérlegelésnek tág teret engedő meghatározás, amelynek 
nem igen lenne helye egy állami normában. A Yahoo esetére 
emlékezve, ahol a francia bíróság arra kötelezte az amerikai 
székhelyű Yahoo-t, hogy az általa működtetett keresőszolgálta- 
tást állítsa át úgy, hogy francia felhasználóktól kezdeményezett 
keresések esetére ne tegye elérhetővé az Amerikában amúgy 
nem illegális, náci relikviákat hirdető web oldalakat, megálla- 
pítható, hogy a magyar AltaVizsla és más keresőprogramok 
fenntartói is hasonló, de még kártérítés megfizetésére is köte- 
lező határozatokra számíthatnak ezen szakasz alapján. A bi- 
zonytalan megfogalmazású jogszabályok végső értelmezését 
mindig a kialakuló bírói gyakorlat adja majd meg, de mint ügy- 
véd állítom, hogy nyilván nem a helyes jogszabályi szövegezés- 
re utal, amikor a tanácsért hozzám forduló szolgáltatónak adott 
esetben a kezemet széttárva nem tudom megmondani, hogy mi- 
lyen döntésre számíthat majd az adott ügyben. 

A szolgáltatók tehát a törvényi logika szerint általában nem fe- 
lelnek azokért a jogsértő tartalmú információkért, amelyekhez 
való hozzáférésben valamilyen módon közreműködtek, de ame- 
lyek jogsértő mivoltáról nem volt tudomásuk. Ez a megoldás 
rendben is lenne, ha nem toldaná meg a jogalkotó azokkal a to- 
vábbi feltételekkel a mentesülés esetét, amelyeknek a szolgál- 
tató valójában már csak akkor tudna ténylegesen megfelelni, ha 
vállalná az előminősítést, vagyis mintegy előzetes bíróságként 
eljárva vállalná annak felelősségét, hogy eldöntse, hogy a hoz- 
zá érkezett panasszal érintett információ jogsértő-e vagy sem, 
vagy van- e olyan tény vagy körülmény, amely valószínűsítené, 
a jogellenességet. Ez a megoldás ténylegesen arra fog vezetni, 
hogy a szolgáltató félve az esetleges kártérítési felelősségtől, 
minden további nélkül, automatikusan el fogja távolítani az in- 
formációt, vagy megakadályozza az ahhoz való hozzáférést, ha 
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bármilyen arra utaló jelet kap, hogy az esetlegesen jogsértő tar- 
talmú. Így az eredetileg tervezett, széles körű notice and take 
down eljárás helyett egy rosszabb, a tartalom szolgáltatójának 
jogorvoslati lehetőséget nem adó megoldás született. 

A notice and take down eljárás lényege ugyanis az, hogy az isme- 
retlen tartalomszolgáltatót kilétének felfedésére kényszeríti, ha az 
ragaszkodik a jogsértő tartalom elérhetőségéhez. Vagyis ha valaki 
azt észleli, hogy valamely Interneten található információ jogsér- 
tő, és az információt elhelyezőt nem tudja azonosítani, úgy az 
azonosítható Internet szolgáltatót felhívja a jogsértő tartalom el- 
távolítására vagy a hozzáférés megakadályozására. E felhívásnak a 
szolgáltató - a tartalom szolgáltatójának egyidejű értesítése mel- 
lett - köteles eleget tenni. A tartalom szolgáltatója azonban a sa- 
ját azonosításához szükséges adatok közlésével kérheti az infor- 
máció visszahelyezését, és az ahhoz való hozzáférés helyreállítá- 
sát. Az eljárás lényege tehát az, hogy a panaszos számára azono- 
síthatóvá, és így perelhetővé tegye a tartalom szolgáltatóját. Az a 
tartalomszolgáltató tehát, aki hajlandó vállalni a felelősséget az 
általa szolgáltatott tartalomért, kilétének felfedésével elérheti an- 
nak visszahelyezését illetve a hozzáférés helyreállítását. 

Az eljárás nem túlságosan terjedt el, leginkább az önszabályozó 
kódexekben találkozhatunk vele. Az elektronikus kereskedelem- 
ről szóló magyar törvény tervezete azonban eredetileg erre ala- 
pozta a jogsértés elleni hatékony védekezést. Aggályos volt 
azonban, hogy ha bárkinek bármilyen jogsértés esetére nyitva 
hagyjuk az eljárás megindítására a lehetőséget, úgy számos 
olyan eset lesz, ahol ezzel a joggal visszaélve ténylegesen a vé- 
leménynyilvánítás szabadságát korlátozzák, vagy éppen fontos 
üzleti akciót akadályoz meg a versenytárs. Ezért a szakmai lobbi 
nyomására a törvénybe már szűkebb körre vonatkoztatva, a 
szerzői jog megsértésének orvoslására épült be a notice and 
take down eljárás. Így akinek szerzői jogi védelem alatt álló jo- 
gát sért egy adott információ, kérheti annak eltávolítását. Az 
információt elhelyező tartalomszolgáltatónak pedig 8 nap áll 
rendelkezésére a kifogás előterjesztésére. Ha kellőképpen azo- 
nosította magát, úgy a panaszosnak további 10 nap áll rendel- 
kezésére ahhoz, hogy keresetet nyújtson be a tartalomszolgál- 
tatóval szemben. Ez esetben az információhoz való hozzáférést 
ismét megszünteti az Internet szolgáltató a bíróság döntéséig. 
Az eljárás így tehát csak a szerzői jogok fokozott védelmét ga- 
rantálja egy olyan környezetben, ahol a szerzői jog megsértése 
könnyebben és büntethetetlenül történhet, mint a nyomtatott 
vagy hagyományos média világában. Gyakorlatilag azonban a 
szolgáltatói felelősség ismertetésénél bemutatott más, a jogsér- 
tő információ eltávolítására, illetve a hozzáférés megakadályo- 
zásra vonatkozó kötelezettségeket tekintve megállapíthatjuk, 
hogy az eltávolítási kötelezettség minden esetben terheli a 
szolgáltatót, ha annak akár csak gyanúja merül is fel, hogy va- 
lamely adott tartalom jogsértő lehet. Ezekben az esetekben 
azonban, a tartalomszolgáltatónak még csak a gyors jogorvos- 
latra sem nyílik lehetősége. 

Noha a törvény hatálya deklaráltan csak a véleménynyilváníi- 
tás szabadsága által védett terület határáig terjed, e rendel- 
kezések arra utalnak, hogy a jogalkotó e határon átlépve bi- 
zony a véleménynyilvánítás szabadságát is bizonyos mérté- 
kig korlátozta. 
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ASP Suli: 


Outlook Wap Access 


Az elmúlt két hónapban megismerkedtünk a WML programozás alapjaival. 

Most itt az ideje, hogy valami maradandót alkossunk: cikkünkben az Exchange 
2000 CDO objektummodellje segítségével megvalósítjuk az Outlook Web Access 
szuperkompakt változatát: ez lesz az Outlook Wap Access. 


A CDO for Exchange 2000 

A CDO for Exchange 2000 objektummodell (CDOEX) az általunk 
már korábban megismert CDO objektummodell-család legfiata- 
labb tagja. A CDOEX az Exchange 2000 telepítésével kerül a szá- 
mítógépre, működése során az Exchange 2000 és az Active 
Directory környezetet igényli (az előbbit ráadásul lokálisan) . Ép- 
pen ezért tartsuk fejben, hogy az [1] címről letölthető példa- 
programok (a példaként bemutatott fájlok neveit zárójelben min- 
dig jelezzük) csak az Exchange kiszolgálóként üzemelő számító- 
gépen működnek majd megfelelően. A CDOEX lefedi a teljes Ex- 
change-funkcionalitást, azaz segítségével szinte bármit megte- 
hetünk, amit az Exchange-ben meg lehet tenni (levelet írni-ol- 
vasni, naptárat, névjegykártyákat kezelni, találkozót szervezni, 
stb.) - mi itt szigorúan a levelek olvasásában szorítkozunk a 
CDOEX segítségére. Aki ennél többet akar, az a CDOEX teljes re- 
ferenciáját megtalálja a [2] címen. 


A kiszolgáló előkészítése 
Mielőtt a komolyabb munkába belekezdenénk, hozzunk létre a 
webkiszolgálónkon egy virtuális mappát, ahova majd az alkal- 
mazásunk kerül. Ne felejtsük el véghezvinni az alábbi beállítá- 
sokat (teljeskörű leírásuk a tech.net magazin 2002/02. számában 
található meg): 
2 Definiáljuk a WML tartalomtípusokat (.wml, .wbmp) 
0 Kapcsoljuk ki a webalkalmazásban a munkamenetek (Session) 
kezelését, úgysem lesz rá szükség 
-? Engedélyezzük a nyíltjelszavas (Basic) felhasználóazonosítást. 
Igen, Kedves Olvasó! Utóbbi beállítás természetesen nem más, 
mint egy kövér kis biztonsági rés. A titkosított wapos kommuni- 
káció nem jelen cikkünk témája, ezért egyelőre a hagyományos 
felhasználóazonosítást választjuk. Éles környezetben el kellene 
gondolkodnunk azon, hogy kinek és mihez engedélyezzük a hoz- 
záférést, hiszen az így elfogott hálózati forgalomból a felhaszná- 
ló jelszava könnyen visszafejthető. Az itt bemutatott példaalkal- 
mazás nem csak ezen a ponton sántít, biztosan sok helyen egy- 
szerűbben, vagy főleg elegánsabban is meg lehetne oldani dol- 


A lényeg a körítés 

A webalkalmazás beállításait, a tartalomtípusok helyes működé- 
sét kipróbálhatjuk, ha létrehozzuk az OWA bejelentkező képer- 
nyőjét képező oldalt. Ehhez korábban már - nem kis munkával 
:-) - létrehoztunk egy csinos kis logót (owa.wbmp) is. Az oldal- 
ban (default.asp) definiált kód pedig a következőképpen fest: 


4 
If InStr(Reguest.ServerVariables( "HTTP. ACCEPT" ) , 
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B "wml") - 0 Then 

Response.Redirect "http://mail.falatrax.hu/ 
8 exchange/" 1 
End If 


Response.ContentType - "text/vnd.wap.wml" 
42 


A kód elején - biztos, ami biztos - 
megnézzük, hogy a böngésző ké- 
pes-e a WML tartalomtípus fogadá- 
sára (azaz, a HTTP ACCEPT fejlécek 
tartalmazzák-e a , wml" szót). Ha 
nem, akkor valószínűleg nem 
wapos, hanem hagyományos bön- 
gészővel van dolgunk, amit egy- 
szerű átirányítással továbbküldünk 
a hagyományos Exchange Outlook 
Web Access felé (1). Ellenkező 
esetben kezdődhet a wapos feldolgozás. Legelső dolgunk legyen 
mindig a wml tartalomtípus beállítása: 


Response.ContentType - "text/vnd.wap.wml" 


Az oldal ezután a logót, majd egy hivatkozást tartalmaz a posta- 
ládához vezető oldalra. Ezt a hivatkozást a könnyebb kezelhetőség 
érdekében hagyományos link (caz2) és menüparancs (cdozs/cgoz) 
formában is definiáltuk, bár erre nem lenne feltétlenül szükség. 


Meg kell jegyeznünk, hogy a wapos programozás aranysza- 
bályaiban valahol az elsőközött szerepel, hogy az idő, a 
sávszélesség (és a pénztárcánk) kímélése érdekében tar- 
tózkodjunk a hasonló, cél nélküli, gyakorlatilag értelmet- 
len üdvözlő képernyőktől. Demonstrációs célra viszont ki- 
tűnően megfelel, és aki ezt az oldalt nem szeretné látni, 
hivatkozhat majd közvetlenül a postaláda címére is. 


A tools.asp fájlban néhány olyan függvény található, amit több 
helyről is használni fogunk, és felesleges lett volna többször 
megírni. Ilyen többek között a felhasználó postaládája helyének 
keresése, vagy maga a postaláda megnyitása is. Az első függ- 
vény mindjárt az előbbi feladatot végzi el: 


USERDOMAIN - "efalatrax.hű" 


Function GetMailboxURL( sUser ) 


ceNüS. As 
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On Error Resume Next 


pl Set oPerson - Server.CreateObject 
ő ("CDO.Person") 
strURL - "mailto:" 8 slUser § USERDOMAIN 


oPerson.DataSource.Open strURL 
GetMailboxURL - 
4 oPerson.Getlnterface( " IMailbox" ) . Inbox 


Set oPerson - Nothing 


If Err.Number € 0 Then 
GetMailboxURL — "" 
End If 
End Function 


A Person (CDO.Person) objektum egy Active Directory-beli fel- 
használót személyesít meg. A felhasználó adatait a Person objek- 
tum IDataSource interfésze (amit a .DataSource jellemző segítsé- 
gével érünk el) segítségével tölthetjük be, ehhez az Open() me- 
tódusnak át kell adnunk az objektumra mutató URL-t. Esetünkben 
ehhez tökéletesen megfelel a felhasználó nevéből képzett e-mail- 
cím (a USERDOMAIN változó persze a valós e-mail domaint tartal- 
mazza). A lényeg, a bejövő postafiókra mutató URL pedig a 
Person objektum IMailbox interfésze segítségével kérdezhető le. 
Ehhez először magát az interfészt kell előcsalogatnunk az objek- 
tum Getlnterface() metódusa segítségével. Maga az IMailbox in- 
terfész egy felhasználó komplett postaládáját jelképezi, bejövő, 
kimenő mappákkal, naptárral, egyebekkel együtt. A beérkezett 


tartalmazza. Az elérési út egyébként valahogy így fest: 


file://./backofficestorage/falatrax.hu 
$ /MBX/mick/Inbox 


Ennek az elérési útnak a birtokában már könnyű hozzáférni a 
postaláda adott mappájában található levelekhez. 


A postaláda-Recordset 

A CDOEX szorosan összenőtt az ADO objektummodellel (is). Ha pél- 
dául egy mappa leveleit szeretnénk böngészni, az Exchange adatbá- 
zist elérhetjük a megszokott módon, ADO-ból, Recordseteken keresz- 
tül, az ADO minden előnyét kihasználva. Ez annak köszönhető, hogy 
az Exchange 2000-hez készült egy OLE DB provider, aminek segítsé- 
gével az adattár közvetlenül elérhető. A bejövő üzenetek megnyitá- 
sának eredménye tehát egy ADO Recordset lesz (az ADO adat- 
báziskezelésről többek között novemberi számunkban írtunk, de az ob- 
jektummodell referenciája elérhető a [3] címen). A következő meg- 
emésztendő feladat tehát a Recordset megnyitása, amit ugyancsak a 
tools.asp fájlban találunk, mert több helyen is szükség lesz rá. 


Function GetMailbox(sInboxURL) 
Set oRC - Server.Create0bject( "ADODB.Record") 
oRC.Open sInboxURL 


Set oRS - 

4 Server. CreateObject ( "ADODB.Recordset" ) 
oRS.CursorType - 3 " static 
oRS.CursorLocation -— 3 " client 
oRS.LockType - 1 " read only 

" sSAL - lásd alább 


vöarking With 


oRS.Open sSAL, oRC.ActiveConnection, 3, 1, 1 
út static, read only, text 
oRS.PageSize - 5 
Set GetMailbox - oRS 
End Function 


Legelőször is, egy rekordként meg kell nyitnunk magát a postaládát, 
hogy majd a rekord ,adatbázis-kapcsolatát" felhasználhassuk a 
Recordset megnyitásához. A példaprogramból a könnyebb értelmez- 
hetőség kedvéért kivágtuk a lekérdezéshez szükséges SOL stringet: 


SELECT 
"urn:schemas:httpmail : sendername" As SenderName, 
"urn:schemas:httpmail:fromemail" As FromEmail, 
"urn:schemas:httpmail:from" As From, 
"urn:schemas:httpmail:to" As To, 
"urn:schemas:httpmail:textdescription" As 
4 MsgText, 
"urn:schemas:httpmail:date" As Received, 
"urn:schemas:httpmail:subject" As Subject, 
"http://schemas.microsoft.com/exchange/mid" As 
8 MID 


FROM 
scope ("shallow traversal of """ 
$ 8 sInboxURL 8 """") 


WHERE 
"DAV:isfolder"-false AND "DAV:ishidden"-false" 


ORDER BY 
"urn:schemas:httpmail:datereceived" DESC 


A lekérdezésben kiválasztjuk a nekünk szükséges mezőket (a tel- 
jes lista a referenciában megtalálható) , ezek: 

"0 sendername, from: A feladó teljes neve 

fromemail: a feladó e-mail címe 

to: a címzett neve 

textdescription: a levél törzsének szöveges tartalma (tökéletes: 
automatikus konverzió HTML levélről, nem zavarnak a csatolt 
fájlok, stb.!) 

date: a levél feladásának dátuma 


Pod 


BR 


"0 subject: a levél témája 

"0 MID: a levél Exchange adatbázison belüli egyedi azonosítója 
(MessageID, ennek segítségével hivatkozhatunk később az 
üzenetre). 

A FROM részben jelezzük, hogy a postafiók (fentebb látott) URL- 

je és az azalatti mappákban keresnénk, a WHERE kitételben pe- 

dig azt, hogy a mappák illetve a rejtett (törölt, rendszer, stb.) 

üzenetek ne kerüljenek be a válaszba. Végül, az egész listát a 

levelek beérkezési időpontja szerinti csökkenő sorrendbe ren- 

dezzük. A Recordset megnyitása után még beállítjuk a lapmére- 

tet 5-re (ennyi üzenetet kezelünk majd oldalanként). 





A bejövő üzenetek listája 

Ennyi előkészítés után lássuk az inbox.asp kódját, ami a bejövő 
üzenetek lapozható listáját varázsolja elénk. Mindenekelőtt je- 
lezzük, hogy a tools.asp kódját is szeretnénk elérni az oldalból: 


£1!-- $include files"tools.asp" --2 


itdats JJ BOR: 03. 





A postaláda kódja így folytatódik: 


If Reguest.ServerVariables( "AUTH USER") - "" Then 
Response.Status - "4OL Unauthorized" 
Response.End 


End If 


Response. ContentType - 
Response.Expires -— -1 
Response.AddHeader "Cache-Control", 
kj "no-cache, must-revalidate" 


"text/vnd.wap.wml" 


Response.AddHeader "Pragma", "no-cache" 
Mindenekelőtt, ellenőrizzük, hogy a felhasználó bejelentkezett-e. 
Ha nem (azaz a megadott felhasználónév üres), akkor mindössze 
egy ,401 Unauthorized" HTTP hibaüzenetet adunk vissza, és rög- 
tön be is fejezzük a működést. Ennek hatására a böngésző beké- 
ri majd a felhasználónevet és jelszót, majd újra próbálkozik. 
Ezután beállítjuk a wml tartalomtípust, majd jelezzük, hogy az 
oldal ne kerüljön sehol gyorsítótárba (-1-es lejárati idő, Cache- 
Control, Pragma fejlécek). Ez a néhány sor a webalkalmazásunk 
minden fájljának elején megtalálható. A következő lényegesebb 
részlet a fájlban: 
Set oRS - GetMailbox(sInboxURL) " 


ld. tools.asp 


ÖRS. Filterem "e 


If oRS.RecordCount - D Then 
Response.Write "Cp align5-"center"2Nincs új 
$ üzenet." 
Response.Write "Cbr/2" 

Else 
If Reguest("pg") £ "" Then 

oRS.AbsolutePage - CIlnt(Reguest("pg")) 

End If 
Response.Write "€p align5s"center"2£b2" 8 
S RS.RecordCount 8 " üzenet. €/bo" 
Response.Write oRS.AbsolutePage a "/" 8 
4 ORS.PageCount 8 " old.€/p2" 


Miután a tools.asp-ben már bemutatott GetMailbox() segítségé- 
vel hozzájutottunk az üzeneteket tartalmazó Recordset-hez, a 
Recordset .RecordCount jellemzőjét kiolvasva kiderül, hogy van- 
e levél. Ha ez az érték 0, akkor a postaládában nincs üzenet. Ha 
nem, következhet az üzenetek listázása. A korlátozott méret 
miatt oldalanként csak néhány üzenet listázására van mód, 
ezért lapozni kell. Korábban már bemutattuk, hogy az ADO 
Recordset objektum hogyan támogatja ezt. Az .AbsolutePage 
jellemző az aktuális oldal sorszámát jelzi (az oldalak méretét 
már a tools.asp-ben beállítottuk). Ha az .AbsolutePage értékét 
felülírjuk (mint itt is, ha a kérésben szerepelt a pg változó), ak- 
kor a Recordset kurzor is az aktuális oldal első rekordjára ugrik. 
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NOKIA 


Mick postaládája €5 
8 üzenet. 2/2 old. 


NOKIA 


 mick postaládája — 
8 üzenet. 1/2 old. 


NOKIA 
(Service options — 
, Select 
(Következő oldal 
új üzenet 
Select 





0 A beérkezett üzenetek közötti navigációt az ADO 
Recordset lapkezelése segíti. Ha szükség van rá, menüparan- 
csokat (második kép), és hagyományos linkeket (harmadik 
kép) is definiálunk a lapozáshoz 


A szöveg normalizálása 

Ne felejtsük el, hogy az oldalak maximális mérete erősen köti a ke- 
zünket, ezért a feladók, címzettek, témák hosszát ellenőriznünk 
kell, mielőtt a telefonra küldjük. Ezért a kódban számos helyen lát- 
ható, hogy a Left() függvény segítségével itt-ott elvágjuk a szöve- 
geket. A másik nagyon fontos tényező, hogy bizonyos karaktereket 
konvertálnunk kell a WML-beli azonosítóra. A Server. HTMLEncode() 
metódus erre elvileg megfelelő lenne, de az például a tipikusan 
WAP-specifikus $ jelet nem alakítja $$-ra - egyszerűbb a saját 
megoldás. Ehhez a tools.asp fájlban definiált Normalize() függ- 
vényt hívogatjuk bőszen szerte a webalkalmazásunkban. 


Az üzenet olvasása 
A következő feladat az üzenet teljes megjelenítése (read.asp). 
Ehhez rendelkezésünkre áll az üzenet azonosítója: 

sMID - Reguest("mid") 
A postaláda-Recordset szokásos módon történő megnyitása 
után az adott azonosítójú üzenetre szűrjük: 


On Error Resume Next 
oRS.Filter - "MID-" 8 sMID 


If Err.Number 2 D Then 
oRS.Filter - 
Response.Redirect( "inbox.asp") 

End If 

On Error Goto 0 


A hibakezelés lényege az, hogy ha a szűrés során bármilyen hi- 
ba keletkezne (pl. nincs ilyen rekord) , akkor visszaugrunk a pos- 
taládához. Ezután a szöveg oldalakra tördelt megjelenítése kö- 
vetkezik (hasonlóan, mint a postaládánál, csak most nem segít 
nekünk a Recordset - mindent kézzel kell csinálni). 


ijzenet olvasása — 


( Téma:Vetközés 


n Egy semmiség, lehet 


Még magamon tartom mozdulat is, mitől 


5 A hosszabb üzeneteket is lapozni kell. A módszer ugyanaz, 
mint a postaládánál (menüparancsok, linkek), csak most nin- 
csenek Recordset-oldalak 
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Üzenet törlése 
Az üzenet olvasása során definiálunk egy menüparan- 
csot, ami az üzenet törlését kezdeményezi. Ez a me- 
nüparancs a del.asp oldalra ugrik, és átadja neki az MID- 
t. Az üzenet törlése során egy írható Recordset-ben megnyit- 
juk a postaládát, azt szűrjük a törölni kívánt áldozat üzenet azo- 
nosítójára, majd töröljük az aktív rekordot (del.asp): 


Set oRec - Server.Createobject( "ADODB.Record" ) 
oRec.Opén sInboxURL 


Set oRSD - Server.Createobject( "ADODB.Recordset") 
ORSD.CursorType - 1 

oRSD.CursorLocation - £ 

ORSD.LockType - 2 


SSAL - "SELECT ""http://schemas.microsoft.com/ 
$  exchange/mid"" As MID " 

8." FROM scope ("shallow traversal of """ 8 
$  sInboxURL a "erje 

8. " WHERE ""DAV:isfolder"" - false AND 
S" DAV:ishidden"" - false" " 


ORSD.Open sSAL, oRec.ActiveConnection, 1 , 2 , 1 
$ " cursor, lock, text 


ORSD.Filter - "MID-" 8 sMID 


oORSD.Delete 
oRSD.Update 


Az Exchange teljes OLE DB integrációjának köszönhetően a re- 
kord törlése egyben a levél törlését is jelenti. 


Új üzenet (és válasz egy üzenetre) 

A két dolog mindössze annyiban különbözik, hogy az utóbbi eset- 
ben átveszünk egy MID-t, így ki tudjuk másolni az eredeti üzenet 
feladóját (ő lesz az új címzett) , illetve témáját. Az eredeti üzenet 
szövegét azonban érthető okokból nem idézzük a levélbe. Az üze- 
net írását mindkét esetben a new.asp végzi, számunkra azonban 
sokkal érdekesebb az üzenet elküldését végző send.asp kódja. 
Mindenekelőtt, a send.asp nem tartalmazza a felhasználóazono- 
sítás kikényszerítését. Ennek az az oka, hogy a levél írása során 
a telefon gyakran bontja a kapcsolatot (időtúllépés miatt), és az 
újbóli kapcsolatfelvétel miatt elveszik a felhasználónév-jelszó 
páros. Ilyenkor újra be kell jelentkezni, ennek hatására viszont 
sok telefonon elveszik az addig bepötyögött adat... kellemet- 
len. Maga a levél elküldése az általunk már korábbról ismert 
CDONTS.NewMail objektum segítségével történik: 


sSub - Reguest("sub") 
sBody - Reguest("msg") 
sPg - Reguest("pg") 


sSub - ConvertToCharset( sSub, "us-ascii" ) 
sBody - ConvertToCharset( sBody, "iso-8859-2" ) 


Set oNewMail - 
b Server . CreateOb ject ( "CDONTS.NewMail") 


oNewMail.From - Reguest( "from" ) 
oNewMail.To - Reguest("tő) 


voörkiny vith 





vindőgs A 


oNewlMail.Subject - sSub 

sBody - sBody § vbCRLF 8 vbCRLF § 
4 "(Sent by Outlook lWap Access]" 
oNewMail.Body - sBody 
oNewMail.Send 


A ConvertToCharset() metódus a tools.asp fájlban található, és 
feladata, hogy (az ADO Stream objektum segítségével) a kapott 
szöveget a megadott kódtáblára konvertálja. Ezután a CDO.Mes- 
sage objektum segítségével a levelet - ha éppen ismerjük a fel- 
használó nevét - elmentjük az elküldött üzenetek mappájába. 


sEmail - sUser 8 0 USERDOMAIN 
sSentURL - GetSentltemsURL(sUser) 


Set olisg - Server.CreateObject("CDO.Message") 


ollsg.From - Reguest("from") 
oMsg.To - Reguest("to") 
ollsg.Subject - sSub 
ollsg.TextBody - sBody 


olisg.DataSource. SaveToContairer( sSentURL ) 


A GetSentltemsURL() függvényt (ami az elküldött üzenetek map- 
pájának URL-jét adja vissza) a tools.asp fájlban találjuk, és a bejö- 
vő üzenetek mappájának lekérdezésétől egyetlen sorban különbö- 
zik: most az IMailbox interfész SentIltems metódusát adjuk vissza: 


GetSentIltemsURL - 
4 oPerson.Getlnterface( "IMailbox" ) . SentItems 


"— Levél küldése, ..— 
" üzenet elküldve. 


—— új üzenet —— új üzenet 
Feladó: jar 

( [mickénetacademia.n..] (Hellól 
Címzett: 


icke 
netacademianet 
Options 


5 Levélküldés az Outlook Wap Accessel 


További teendők 
Jó néhány dolog persze megoldatlan maradt így is. Rögtön fel- 
merülhet például, hogy valahogy kiküszöböljük a felhasználó- 
azonosítás hiányában bárki által kihasználható levélküldözgető 
oldal (send.asp) elérését. Gondolkodhatunk azon, hogy szűrőket 
építsünk be a kevésbé fontos levelek elrejtésére (az SOL lekér- 
dezésbe nagyszerűen belekódolhatjuk a szűrő kifejezéseket) . Nyi- 
tott probléma a biztonságos felhasználóazonosítás, a kódtáblák 
teljes körű és helyes kezelése... akit tehát érdekel a téma, íme 
egy jó kiindulási alap. Jó szórakozást! 
Fülöp Miklós 
mick 2netacademia.net 
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[1] http://technet.netacademia.net/download/asp/owa/ 
[2] http://msdn.microsoft.com/library/en-us/wss 
/wss/ cdoex cdo for exchange 2000 server.asp 

[3] http://msdn.microsoft.com/library/en-us/ 
ado270/htm/mdmscadoapireference.asp 
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Az előző két részben megtekintettük az osztályok alapvető lakóit, megnéztük, 
hogyan kezeli a .NET a típusaink által igényelt memóriát. 

Most továbbhaladunk az objektumorientált jellemzők mentén, és megnézünk 
néhány fejlettebb típust, amelyek nagy segítséget jelentenek áttekinthető, 
könnyen bővíthető és karbantartható programok írásában. 


Interfészek 

A mai objektumorientált rendszerekben az objektumok közötti csa- 
tolás, függőség csökkentésére az egyik legelterjedtebben alkalma- 
zott eljárás az interfészek használata. Habár a VB6 nem volt objek- 
tumorientált nyelv, a COM komponensek használata és írása során 
- még ha nem is tudtunk róla - állandóan COM interfészeket defi- 
niáltunk és alkalmaztunk, de ezt a VB ügyesen elrejtette előlünk. 
Aki azonban akart, még VB6-ban is különválaszthatta a COM inter- 
fész definiálást és az implementációját (ld. Implements kulcsszó). 

A .NET Framework Class Library (FCL) rengeteg helyen használ- 
ja ki az interfészek adta előnyöket könnyen kiegészíthető, ké- 
nyelmesen használható alapkönyvtár felépítésére. 

Mi takar hát az interfész fogalom az 00OP világban? Az interfész 
egy formai és működésbeli szerződés, amelyhez minden leszár- 
mazott osztálynak kötnie kell magát. Közelebbről: az interfész 
definiálja mit kell csinálni, milyen metódusokat kell tudni, a le- 
származott osztály pedig megvalósítja, implementálja a metó- 
dusokat, azaz tudja hogyan kell azt megvalósítani. 

Gyakori például, hogy egy-egy funkcionalitáshalmazt sokféle, na- 
gyon különböző feladatra készített osztálytól is elvárunk. A funk- 
cionalitás konkrét megvalósítása minden osztály esetén más és 
más lenne, csak az azt megvalósító metódusoktól elvárt működés 
lenne azonos. Ezt meg lehetne oldani úgy, hogy egy-egy abszt- 
rakt alaposztályban deklaráljuk a szükséges metódusokat, majd a 
konkrét osztályokat leszármaztatjuk ebből, így kötelezően imple- 
mentálnunk kell az alaposztály absztrakt metódusait (mert absz- 
traktok voltak, azaz nincs a metódusoknak törzse). Viszont erre a 
célra nem a legszerencsésebb megoldás az öröklődés, különösen 
akkor, ha többféle, különböző jellegű funkcionalitáshalmazt is 
meg kell valósítani. Ebben az esetben többszörös öröklődést kel- 
lene használni, ami számos gubanc forrása szokott lenni, éppen 
ezért például a .NET-ből és a JAVA-ból száműzték is. 

Az absztrakt alaposztályból öröklést általában akkor szoktuk be- 
vetni, ha a szülőosztály és a leszármazott között is-a (a dog is an 
animal...) kapcsolat van. Például a Kutya az egy Állat, így mindent 
tud, amit egy állat általában tud, azért a minden állatra közös 
funkciót bele lehet rakni egy alaposztályba, és ebből leszármaztat- 
ni a kutyát (macskát, satöbbi). Ebben az esetben általában kihasz- 
náljuk a tagváltozók öröklődését is, hiszen az állatoknak sok olyan 
közös jellemzője van, amit elég az Állat osztályban (egy helyen) 
definiálni, és az összes leszármazott állat örökölni fogja azt: 


public abstract class Allat ( 
abstract public void Eszik(string kaja); 


public string Szin; //nem abstract! 


working With 


windows 7 


public class Kutya : Állat ( 
public override void Eszik(string kaja) ( 


Console.WriteLine( "Nyam-nyam (0) -t eszek.", e 
kaja); ep 
a 
) a 
a 
public string Ugat(int hanyszor) ( a 
string ü5"": a 
m. 
for(int i-O;idhanyszor;itt) ut-"Vau "; a 
return u; —- 
H 
) H-H 
H 
public void Pitizik() ( A 
Console.WriteLine( "Kolbászt, plíz!!!"); 8 
) un 
N 
] pe 
//Teszt: 
Kutya k - new Kutya ( ); 
k.Szin - "barna"; 


k.Eszik( "répa" ); 

k.Pitizik(); 
Console.WriteLine(k.Ugat(3)); 
Console.ReadLine( ) ; 
7/Kimenet: 

Nyam-nyam répa-t eszek. 
Kolbászt, plíz!!! 

Vau Vau Vau 


Vannak olyan állatok, amelyek képesek harcolni. Ezt a funkciót 
nem rakhatjuk bele az Állat alaposztályba, mert nem minden 
példányra jellemző a harcikedv. Azt sem mondhatjuk, hogy va- 
lamelyik leszármazott szinten vezetjük be, mert annyira egyéni 
ez a jellemző. Egyéni, de sokféle állat (objektum) tudhatja. 
Mivel a különböző funkcionalitáshalmazok ráerőltetésére megfe- 
neklünk az örökléssel 
(vagy túlságosan bonyo- 
lulttá válik a modellünk) , 
itt az ideje, hogy belép- 
jenek az interfészek. 
Formailag egy interfész 
deklarációja majdnem ugyanaz, mint egy osztályé (class), csak 
nincsenek benne hozzáférést szabályzó kulcsszavak (private, pro- 
tected, stb.), mert minden tag automatikusan nyilvános, és nincs 
megírva a tagok törzse, mert azt majd egy, az interfészt imple- 
mentáló osztály fogja leírni. 

Lássuk hogyan lehet definiálni egy IHarcos interfészt, amelyet 
majd minden harcias osztály (Kutya, Macska, bármi más nem állat 
osztály is) implementálhat: 


A többszörös öröklődést 
száműzték a .NET-ből 
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interface IHarcos ( 
void Csip(); 
void Karmol(); 


Konvenció szerint az interfészek nevét nagy I-vel kezdjük. Örö- 
költessünk le egy Pitbullt a Kutya osztályból, és tegyük őt har- 
cossá, azaz támogassa, valósítsa meg az IHarcos interfészt: 


public class Pitbull : 
public void Csip() ( 
Console.bWriteLine("Csípek mint állat, mert 
$ egy dög Pitbull vagyok!!!"); 
) 
public void Karmol() ( 
Console.WriteLine( "Karmolok" ) ; 


Kutya, IHarcos ( 


Ji 


A Pitbull : Kutya azt jelöli ki, hogy a Pitbull osztály örökli a Ku- 
tya osztály összes jellemzőjét (metódus, tagváltozó, stb.). Ez a 
klasszikus öröklődés. Az IHarcos azt jelöli, hogy a Pitbull osztály 
implementálja az IHarcos interfészt, azaz megvalósítja az összes 
benne definiált metódust. A kettő nagyon különbözik, de sajnos 
a CH szintakszisa a kettőt összemossa, emiatt különösen jó, ha 
tartjuk magunkat az I kezdőbetűs interfész nevekhez. Ez azért 
van, mert a C4-- formátumához közelivé akarták tenni a nyelvet. 
Ebből a szempontból szerintem jobb a JAVA-s formátum: extends 
kulcsszó az öröklésre, implements az implementációra. 
Az interfészekben kijelölt funkcióknak természetszerűleg nem 
lehet törzse, azt majd az implementáló osztályok írják meg. 
Az interfészek öröklődhetnek egymásból, így az implementáló 
osztályoknak meg kell valósítani az összes interfész (papa, 
nagyapa, stb.) műveleteit is. 
Egy interfész teljesen absztrakt, így tagváltozókat nem tartal- 
mazhat, csak ,metódusjellegű" tagokat: metódusokat, property 
definíciókat, eventeket és indexer definíciókat. (Az indexer 
nagyvonalakban az a speciális elérő metódus, amivel az indexe- 
lést kijelölő [] -jelek működését lehet leírni. ) 
Egy interfészt megvalósító osztálynak az interfész összes tagját 
meg kell valósítania. Ezt azért követelik meg a nyelvek, mert a 
hívók látva, hogy mi megvalósítunk egy interfészt, bátran bele- 
hívnak bármelyik implementált metódusba, így ha nem szolgál- 
tatnánk mindegyikhez implementációt, az nagy hiba lenne. 
Ha van egy macskánk, ami szintén harcos, akkor azt így defi- 
niálhatjuk: 
class HarcilMacska : Allat, IHarcos 
void IHarcos.Csip() ( 
Console.WriteLine("Csípek, mert (0) 


harcicica vagyok.", Nev); 
$ 
void IHarcos.Karmol() ( ...) 
public override void Eszik(string kaja) ( ...) 


public string Nev - "Kormos"; 


Látjuk, hogy az implementáció során ki lehet írni az interfész 
nevét is, nem csak a megvalósított metódusokét. Ezt hívjuk exp- 
licit interfész implementációnak. Ez egy nagyon furcsa jószág, 
mert ebben az esetben a megvalósított interfésztagok nem lát- 
szanak a megvalósító osztályra mutató referencián keresztül, 
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mintha nem is lennének részei a megvalósító osztálynak. 
A Pitbull osztálynál ezzel nem volt gond: 


Pitbull p - new Pitbull(); 


p.Csip(); 
Csípek mint állat, mert egy dög Pitbull vagyok!!! 


Azaz a megvalósított metódus úgy érhető el, mintha mindig is 
az osztály része lett volna. 
Ezzel szemben a HarciMacskánál ezzel megbukunk: 


HarciMacska m - new HarciMacskac( ); 

m.Csip(); //hiba, nincs Csip() metódus 
7//"HarciMacska" does not contain a definition 
B for "Csip" 


A Csip metódus eléréséhez a HaziMacska osztályreferenciát át 
kell kasztolunk IHarcos-ra, és azon keresztül már elérhető a kí- 
vánt metódus: 


IHarcos h - (IHarcos) m; 
h.Csip(); 


Egy kicsit skizofrén az explicit implementált tagok láthatósága: az 
osztályreferencián keresztül nem láthatóak, így ebben ez értelemben 
egyéniek (private), másfelől viszont az őket deklaráló interfészen ke- 
resztül kitűnően láthatóak, így ebben az értelemben publikusak. 
Mikor kell ilyen kórtani esetekhez nyúlnunk? Két esetben. Ha 
van olyan funkcionalitás, amit szeretnénk néhány osztályunkon 
implementálni, de nem szeretnénk, hogy a külvilág, az osztá- 
lyunkat felhasználók közvetlenül elérjék őket, akkor érdemes 
bevetni az explicit interfészimplementációt. Másrészt ha több 
interfészt inplementálunk egy osztályban, akkor névütközések 
is lehetnek a tagok között, azaz lehet, hogy több szülő interfész 
is ugyanolyan nevű tagokat deklarál. Ilyenkor a kiírt inter- 
fésznév miatt egyértelmű az implementáció során, hogy melyik 
tagot implementáljuk, és a hívók is kénytelenek explicit kaszt- 
tal jelezni a szándékukat. 


Interfészalkalmazások a FCL-ban 

A .NET osztálykönyvtár nagyon sok helyen alkalmazza az inter- 
fészeket. Mivel az érték szerinti típusokat definiáló struct is 
implementálhat interfészeket, ezért első ránézésre elég megle- 
pő, de a még az olyan primitív típusok, mint az int is támogat- 
nak jó pár interfészt. Például a ctt int megfelelője a System.Int32, 
amelynek definíciója: 


public struct Int32 
IConvertible 


IComparable, IFormattable, 


Azaz három interfészt implementál. Az IComparable-t azon osz- 
tályok vagy struktúrák valósítják meg, amelyeken lehet értel- 
mezni sorrendet, például számokon, dátumokon, stringeken. Mi- 
vel minden osztályon vagy struktúrán másként kell értelmezni a 
kisebbség-nagyobbság fogalmát, ezért minden egyes típusnak 
külön-külön meg kell valósítani ezt az interfészt. Ez az interfész 
egyetlenegy metódust kér az implementálóktól: 


int CompareTo(object obj); 


Azaz vár egy objektumot, amelynek a típusa tipikusan ugyanaz, 
mint az implementáló osztályé, és kisebb, mint egyet ad vissza, 
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ha a paraméterként átadott típus kisebb, mint a példány érté- 
ke, 0-t, ha egyenlő és pozitív számot, ha nagyobb. 
Például két integer esetén: 


int a s 5, b5s8; 
Console.bWriteLine( a . CompareTo(b) ) ; 
-k 


Látható, hogy nem explicit implementálja az int az IComparab- 
le-t, mert akkor nem tudtuk volna elérni a CompateTo-t, csak így: 


IComparable i - (IComparable) a; 
Console.WriteLine( i . CompareTo(b) ) ; 


Vagy egy sorban: 
Console.WriteLine( ( ( IComparable) a) . CompareTo(b) ) ; 


Az IFormattable-t azok a típusok implementálják, amelyeket 
többféleképpen is lehet stringként, szövegként reprezentálni. 
Például tudjuk, hogy a dátumok szinte minden országban más- 
ként néznek ki, vagy ismerjük a tizedespont kontra tizedesvessző 
problémakörét a magyar területi beállítások kapcsán. A típusok 
kiíratásakor általában az aktuális területi beállításokat használja 
a .net, de ettől eltérhetünk ezen az interfészen keresztül. 
Ennek is csak egy metódusa van: 


string ToString( 
string format, 
IFormatProvider formatProvider); 


Hogy szebb legyen az élet ez a metódus is hivatkozik egy inter- 
fészre, amelyet szintén meg kell valósítani. Ha az előbbi egé- 
szünket akarjuk megformázni, akkor például a FCLNumberFormat- 
Info osztály ad egy megvalósítást. 


NumberFormatIlnfo fi - new NumberFormatlnfo( ); 
fi.NumberGroupSeparator — ","; 
fi.NumberGroupSizes - new int [] (3,2,2 

int x - 1234557890; 


Ezek után a formázott kiíratás: 


Console.WriteLine(x.ToString("N", fi)); 
2,23,45,bh7,890.00 


Az N jelöli, hogy csoportonként tagolt számkiírást szeretnénk, a 
második paraméter egy IFormatProvider megvalósítás. Ha min- 
denáron ragaszkodunk az explicit interfészeken keresztüli 
eléréshez, persze az is megy: 


Console.WriteLine( 
( (IFormattable)x) .ToString("N", fi)); 


Végül pár szó az IConvertible interfészről. Ez a típusok közötti 
konverzió kedvéért született (például amikor egy szövegből egy 
számot kell kihámozni). A legtöbb típus explicit interfészimple- 
mentációval támogatja, azaz közvetlenül nem is érhető el, csak 
ha lekérünk egy IConvertible interfészt: 


int y-8; 
IConvertible yc - (IConvertible) y; 
byte by - yc.ToByte(null); 
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Int32 esetén a tényleges konverzió a System.Convert 

osztály statikus metódusai segítségével történik, és ál- 

talában mi is ezt szoktuk használni az IConvertible 

közvetlen hívása helyett. Máskor meg a System.Convert 

használja az adott típus IConvertible interfészét. Számunkra 
általában mindkét út nyitott, de az ajánlás szerint használjuk a 
Convert osztályt. 


Delegatek 

Egy delegate megközelítőleg nem más, mint egy típusos függ- 
vénypointer. A segítségével írhatunk olyan általános algoritmuso- 
kat, amelyeknek nem közönséges adatokat adunk át paraméterül, 
hanem egy delegatet, amelyen keresztül a hívott képes meghívni 
egy általunk szolgáltatott metódust. Azonban a CLR-beli dele- 
gatek nem olyanok mint amiket a Cs-4-ban megszokhattunk, azaz 
nem egy sima pointer, aztán vagy tényleg egy olyan függvényre 
mutat amire a hívni szándékozó felkészült, vagy nem. Ebből nagy 
galibák tudnak adódni C---ban, mert sokszor az általánosítások 
miatt a fordító nem tudja ellenőrizni, hogy megfelelő típusú 
függvénymutatót passzolunk-e át a hívottnak. 

Emiatt a CLR-ben a delegatek szigorúan típusosak, azaz csak ak- 
kor adhatunk át delegaten keresztül egy metódusreferenciát, ha 
annak paraméterlistája és visszatérési értéke (szignatúrája) 
pontosan egyezik a hívott által elvárttal. 

Lássunk egy atomfizikus példát! Tegyük fel, hogy egy atomreaktor 
szivattyúinak vezérlését kaptuk feladatul. Sokféle szivattyúnk van, 
amelyeket egy-egy osztályon keresztül érhetünk el, és mindegyi- 
ket más-más metódushívással lehet bekapcsolni. A feladat az, 
hogy ha a reaktor hőjét elvezető olvadt nátrium hőmérséklete 450 
Celsius fok fülé megy, akkor be kell kapcsolni a hűtőszivattyúkat. 
A reaktoron vannak hőérzékelők, azokon keresztül lehet tudni a 
hőmérséklet pontos értékét. A kérdés, hogy hogyan kommunikál- 
janak a szivattyúvezérlő osztályok és a hőérzékelő osztály? 

A nekiszaladós megoldásban az összes szivattyúosztály időnként 
ránéz a hőérzékelőre, és ha túl magasnak találja a leolvasott ér- 
téket, akkor bekapcsol. Általában ezt hívjuk pollozásnak. Szám- 
talan sebből vérzik: túl sűrű lekérdezésekkel feleslegesen terhel- 
jük a hőérzékelő osztályt a szivattyúk kérdéseivel, túl ritka ese- 
tén pedig lehet, hogy későn vesszük észre, hogy baj van. 

A megoldás nyilvánvalóan az lehet, hogy maga a reaktor hőérzéke- 
lője értesíti a szivattyúkat a határ átlépéséről. Ehhez viszont ismer- 
nie kell az összes szivattyút, azaz hogy az egyes szivattyú osztá- 
lyokban melyik metódust kell meghívni a szivattyúk elindításához. 
Példádul legyen két szivattyúvezérlő osztály az alábbi: 


public class SzivattyuBosch ( 
public void Bekapcs() ( 
Console.WriteLine("Bosch elindult."); 


public class SzivattyuAKkG ( 
public void Indit() 


( 
Console.WriteLine("AKG elindult."); 


A hőérzékelő kódja: 
public class Hoerzekelo ( 


//Itt tároljuk a szivattyúk listáját 
private ArrayList szivattyuk - new ArrayList(); 


eÜ0S. Ú3.: 





etuWöpeJje 3aN 


"III) 


(zsau 


34 


rész) 


(111. 


.Net akadémia 


sa 


private int hofok; 
d 
v public void SzivattyuHozzaad(object szi- 
— — vattyu) ( 


szivattyuk.Add(szivattyu); 


public void Meres() ( 
//vwvalahonnan (hardver) 
//előszedi a homérsékletet 
hofok - 500; 
if (hofok 2 450) GazVan(); 


private void GazVan() ( 
//Szivattyúkat elindítani 
foreach(object sz in szivattyuk) 
( 
if (sz is SzivattyuBosch) 
( (SzivattyuBosch) sz) . Bekapcs( ) ; 
if (sz is SzivattyuAKG) 
( (SzivattyuAKG6) sz) . Indit( ) ; 


Az osztályokat létrehozó indító kód: 


SzivattyuBosch b - new SzivattyuBosch( ) ; 
SzivattyuAKG a - new SzivattyuAKk6( ); 
Hoerzekelo h - new Hoerzekelo( ); 
h.SzivattyuHozzaad(a); 
h.SzivattyuHozzaad(b); 

h.Meres( ); 


Igazából a Mérés metódust a hőérzékelő maga hívná meg belülről, 
periodikusan, de most az egyszerűség kedvéért kívülről hívtuk meg. 
Láthatjuk, hogy a megoldásunkban a Hoerzeklo osztályt felké- 
szítettük a szivattyúk dinamikus hozzáadására, azonban csak 
ezt a két konkrét típust tudja meghívni. Ez tipikus példája a szo- 
rosan csatolt rendszereknek: a hívó osztálynak pontosan ismer- 
ni kell a hívandó osztályokat, azaz egy új hívandó típus esetén 
át kell írni a hívó osztályt. Ez magával vonja annak teljes újra- 
tesztelését, azaz jelentős idővel és költséggel jár a bővítés. 
Általánosan megfogalmazva a probléma a következő: van egy 
osztály, akinek bizonyos belső állapotváltozásaira más osztályo- 
kat értesíteni kell, de úgy, hogy az osztálynak ne kelljen előre 
ismerni az értesítendő osztályok típusát. Ezt a problémát a De- 
sign Patternek világában Observer-Observable (megfigyelő - 
megfigyelhető) mintának nevezik; az állapotot tartalmazó osz- 
tályra Subject metaforával hivatkoznak, ennek változásait az 
Observerek figyelik meg. Annyiban egy picit sánta a pattern ál- 
tal sugallt kép, hogy tulajdonképpen nem az Observerek figye- 
lik meg a Subjectet, hanem a Subject értesíti az Observereket az 
állapotváltozásról, bár sokszor ilyenkor az Observerek vissza- 
nyúlnak a Subjecthez további információkért. 
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Valahogyan csökkenteni kellene a csatolást a Subject (Hoerzeke- 
lo) és a két Observer (a két szivattyú osztály) között. És itt siet- 
nek a segítségünkre a delegatek. 

Ha megfigyeljük, mindkét szivattyút elindító metódus azonos 
szignatúrájú, azaz mindkettő void visszatérési értékű és egyik 
sem vár el paramétereket. Emiatt egy delagate segítségével egy- 
séges módon megfoghatjuk a metódusaikat: 


public delegate void SzivattyuBekapcsolas( ); 


Ez a delegate pont olyan metódusokat képes tárolni, mint amel- 
lyel a szivattyúkat be lehet kapcsolni. 

A Hoerzekelo SzivattyuHozzaad metódusa változatlan, de most nem 
egy-egy osztályreferenciát adunk át neki, hanem a konkrét osztály- 
példányok megfelelő metódusaira létrehozott delegatekét: 


HoerzekelobDelegattel hd - 

new Hoerzekelobelegattel( ) ; 
hd.SzivattyuHozzaad( 

new SzivattyuBekapcsolas(a.Indit)); 
hd.SzivattyuHozzaad( 

new SzivattyuBekapcsolas(b.Bekapcs)); 
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Fontos látnunk, hogy a 4 illetve 6-os sorokban nem történik 
meg a metódushívás, csak létrehozunk egy delegatet a megfe- 
lelő metódusokra. 

Ezek után a Hoerzekelo osztálynak csak a GazVan() metódusát 
kell átírni, a többi változatlan marad: 


foreach(SzivattyuBekapcsolas szbekapcsolo in 
szivattyuk) ( 
szbekapcsolo( ) ; 


Mivel a tömbünkben most nem objektumreferenciákat, hanem 
delegate példányokat tárolunk, ezért a ciklusban is SzivattyuBe- 
kapcsolas (delegate) típusú objektumokat kapunk vissza. Egy 
delegaten keresztüli hívás ezek után láthatóan roppant egysze- 
rű, egyszerűen a delegatet mint egy metódust meghívjuk. Ha 
lennének paraméterek, azok a delegate utáni zárójelek között 
lennének felsorolva. 

folytatjuk... 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo (onetacademia.NET 


ea Lee ErZ ALU ET- LÉ 


[1]: Letölthető példakódok 
http://technet.netacademia.net/download/net 
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Átjárás a relációs és az xml! világ között II. 


Folytatjuk a relációs adatbázisok és az xml világ közötti átjárást. 
Tovább boncolgatjuk a DataSet osztály szolgáltatásait, és megszemlélünk egy valódi 


virtuózt, az XmIDataDocument objektumot. 


Típusos DataSet (folytatás) 

Az előző alkalommal legeneráltuk a TermekKatalogus nevű típu- 
sos datasetünket (ds), és feltöltöttük a Northwind adatbázis 
Products és Categories tábláival. Emlékeztetőül: 


SalConnection c - new SglConnection("..."); 

SgiDataAdapter aProd - new SglDataAdapter( "SELECT " 

FROM Products", c); 

SgiDataAdapter aCat - 

new SglDataAdapter( 

"SELECT FROM Categories", c); 

" //Ez az a típusos dataset osztályunk, amit az 
77 xsd.exe generált 
TermekKatalogus ds - new TermekKatalogus( ); 
//A dataset tábláinak feltöltése 
aCat.Fill(ds, 
aProd.Fill(ds, 


"Categories"); 
"Products" ); 


Hogy lássuk a séma hatását, egy kicsit átalakítottam a DataSet 
sémáját, a Products táblában a UnitsInStock és a ReorderLevel 
átment attribútumba: 
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E Description string 
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5 A módosított sémában egyes adatbázisoszlopok átkerültek 
attribútumszintre (,A" betű) 


Az adatbázisból feltöltött típusos DataSet-ből xml kimenetet 
generálni már nem művészet: 


ds.WriteXm1( " termekek4 . xml" ) ; 
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cTermekKatalogus?2 
cXxCategories2 
cXCategoryID21£/CategoryID2 
cXcCategoryName2Beverages£/CategoryName2 
cXDescriptionzSoft drinks, ...€C/Description2 
cPicture2FRwvAAIAAAANAAHAFA ...c/Picture2 
£x/Categories2 


KProducts UnitsInStock-"0" ReorderLevel-"D"2 
XKProductID25£/ProductID2 
cXKProductName2Chef Anton"s MixcC/ProductName2 


c/Products2 


Apró, de fontos információk: 

"0 Az xml kimenet csak akkor lesz olyan struktúrájú, mint amit a 
típusos DataSet sémájában előírtunk, ha a DataAdapterek 
Fill() metódusaiban olyan táblaneveket adunk meg, ame- 
lyek egyeznek a megfelelő sémában definiált táblanevekkel. 

2 A WritexmlY) metódusnak átadhatunk egy további paramétert, 
amellyel befolyásolhatjuk a generálódott xml formátumát. 
Például az XmlWriteMode.WriteSchema megadásával kérhet- 
jük, hogy a generálódott dokumentum tartalmazzon egy 
beágyazott sémapéldányt is. Nem meglepő módon ez a 
DataSet mögötti séma lesz, azonban ez nincs összekötve a 
mögötte generálódó xml adatokkal, tehát így közvetlenül 
nem lehet feldolgoztatni egy validáló xml elemzővel. 
A Picture egy image típusú oszlop az adatbázisban, azaz 
nagytömegű bináris adatokat tartalmaz (képeket). Mivel az 
xml szöveges szabvány, a DataSet BASE64 kódolással rakja 
bele az oszlopot a kimenetbe. 
Még tovább alakíthatjuk az xml kimenetünket. A sémánk azt ír- 
ta elő, hogy a gyökérelem alatt lesznek Categories és Products 
elemek. Ennek megfelelő xml kimenetet is kaptunk, először fel- 
sorolva az összes Categories elemet, majd jöttek a termékek ele- 
mei. Azonban mi jól tudjuk, hogy a két adathalmaz között szü- 
lő-gyermek kapcsolat van, ahol a Categories a szülő. Egy kate- 
góriához több termék is kapcsolódhat. Ez a reláció nem igazán 
látszott a kimeneti xml dokumentumon, hiszen például egy cso- 
portosított listázáshoz össze kell vadászni az egy kategóriához 
tartozó termékeket a CategoryID elemek mentén. 

Amikor relációs adatokat képzünk le hierarchikus xml adatokká, ak- 

kor ez egy járható út. Azonban sokszor azt szeretnénk, hogy a szü- 

lőelemek közvetlenül tartalmazzák a hozzájuk tartozó gyermekele- 
meket, beágyazott (nested) gyermekelemekként. Ennek semmi aka- 
dálya sincs, csak akkor úgy kell megfogalmaznunk a DataSet sémát, 
hogy a gyökérelem alatt legyenek a Categories gyermekelemek, és 
azokban lehet tetszőleges számú Products elem. A DataSet szolgai 
módon az új sémának megfelelően fogja generálni a kimenetet. Az 
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egymásba ágyazás szabályát (azaz, hogy a CategoryID 

mentén kell csoportosítani) onnan tudja, hogy az elő- 

ző részben látott módon xsd:key és xsd:keyref segítsé- 
gével előírjuk az adatok kapcsolódását. 

Azonban megspórolhatjuk magunknak az új séma elkészítését. 
Szerencsére a DataSet remekül tudja alakítgatni a sémát (és ezen ke- 
resztül a kimeneti xml dokumentumot is), így az előbbi sémával is 
tudunk egymásba ágyazott, csoportosított kimenetet is generálni. 
Ehhez azt kell tudnunk, hogy a sémában leírt termék-termékcsoport 
kapcsolatot a DataSet Relations kollekcióján keresztül érhetjük el. 
Példánkban ez csak egy elemet tartalmaz, egy DataRelation típusút. 
Ha több tábla is lenne a DataSet-ben, vagy esetleg valamelyik táb- 
la saját magára is hivatkozna, akkor többelemű lenne ez a kollekció. 
Egy relációnak több jellemzője is van, de ami minket most ér- 
dekel, az a Nested nevű jellemző. Ha kézzel, programból hozunk 
létre relációt két tábla között, akkor ennek értéke false, azaz 
nem egymásba ágyazott relációról van szó. Az előbbi sémánk is 
ilyen szerkezetű volt. Azonban a típusos DataSet-ünk létrehozá- 
sa után nyugodtan átírhatjuk ezt a jellemzőt! 


TermekKatalogus ds - new TermekKkatalogus( ); 


A sor lefutása után már ismert a DataSet számára a séma, hisz 
ő egy típusos DataSet. Így a relációt (amelyet a sémában kije- 
lölt kapcsolat miatt hozott létre a DataSet) egy mozdulattal 
átalakíthatjuk beágyazottá: 


ds.Relations[0].Nested - true; 


Persze csak akkor szabad ilyen határozottan belecímezni a Relations 
kollekcióba, ha tudjuk, hogy létezik benne a számunkra fontos relá- 
ció. Összetettebb esetben végig kell gyalogolni a relációkon, és a 
ParentTable, ParentColumns, ChildrTable, ChildColumns jellemzők 
alapján meg tudjuk találni a számunkra fontos kapcsolatot. 
Emellett még azt is kihasználhatjuk, hogy a sémában a relációt 
megneveztük: 


£xs:keyref name-"CategoriesProducts" 
refer-"CategoryKey"2 


Ezen a néven megtalálhatjuk a relációnkat a Relations kollekció- 

ban is: 

ds.Relations["CategoriesProducts"].Nested - 
true; 


Miután háromféle módon beállítottuk a Nested jellemzőt, gene- 
ráltassuk le az xml kimenetet a korábban látott módon: 


cXTermekKatalogus?2 
cXxCategories2 
cXCategoryID21£/CategoryID2 


cCategoryNamexBeverages£/CategoryName?2 


cXKProducts UnitsInStock-"39" ...2 
KXKProductID21K/ProductID2 


£/Products2 


XKProducts UnitsIlnStock-"57" ...2 
KProductID27h£/ProductID2 


£/Products2 
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cx/Categories2 

cXKCategories2 
cXCategoryID22C/CategoryID2 
cxCategoryNamezCondiments£/CategoryName2 


Bemutatkozik az XmIDataDocument 

Jelenleg ott tartunk, hogy képesek vagyunk szinte tetszőleges 
xml formátumra leképezni a lekérdezések eredményhalmazait, 
azonban az adatok szigorúan a forrásadatok által vezérelt hie- 
rarchiában és sorrendben jönnek elő. Mielőtt valaki lefitymálná 
ezt, szeretném jelezni, hogy ez nem csak SOL Serverrel megy, 
hanem bármilyen adatforrással! Mivel az OleDb... osztályokkal 
bármilyen adatforrásra rácsatlakozhatunk, gyakorlatilag min- 
denféle relációs forrásból generáltathatunk xml kimenetet. Ez 
igencsak jól jön régebbi vagy kevésbé fejlett adatbázisrendsze- 
reknél, amelyeket meg kell nyitni xml-en keresztül. 

Az DataSet kimenete egy nagy, az xml szabályoknak megfelelő 
karaktersorozat, amelyet fájlba írtunk ki. Ha ezt XSLT-vel át sze- 
retnénk transzformálni például HTML-lé, akkor egy XmIDocu- 
ment vagy XPathDocument osztály segítségével értelmeztet- 
nünk kell a generált kimenetet, azaz a fáradságos munkával ge- 
nerált kacsacsőröket azon nyomban kidobatjuk az xml parserrel 
(értelmezővel) , hogy az előállíthassa a memóriabeli xml fát. Azt, 
hogy mindez ne fájlon keresztül történjen könnyű kikerülni, 
mert a DataSet-nek van egy GetXml() metódusa, ami stringként 
adja vissza az xml kimenetet. 

Na és? Ez csak fél siker. Valahogyan el kellene kerülni a közbenső 
szöveggé való átalakítást. Egy olyan eszköz kellene, amely anélkül 
képes felépíteni a memóriabeli xml objektumfát, hogy közben át 
kellene alakítani xml szöveggé a DataSet tartalmát. Másképpen fo- 
galmazva a DataSet adatait Infosetként szeretnénk láttatni, anél- 
kül, hogy közben még csak a kacsacsőrök gondolata is felmerülne. 
Ehhez természetesen egy olyan objektumra lenne szükség, 
amely képes közvetlenül olvasni a DataSet tartalmát, és azt úgy 
megjeleníteni a külvilág számára, mintha az InfoSet lenne. Így 
lehetne transzformálni a DataSet tartalmát, mintha csak az egy 
xml forrás lenne, lehetne XPath kifejezéssekkel kiszűrni egyes 
részeit, satöbbi. Jöhet az XmIDataDocument! 

Ő pont erre van kitalálva. Megadunk neki egy DataSet-et, és ő 
ezt kifelé úgy mutatja, mintha egy xml dokumentum lenne. Nem 
készít másolatot a DataSet DataTable-jeiből. Menet közben nem 
alakítja át a DataTablek sorait kacsacsőrös xml doksivá. Ehelyétt 
hozzákapcsolja a DataTablek sorait a saját belső elemlistájához, 
és amikor egy-egy xml elemre vagy attribútumra hivatkozunk 
rajta keresztül, akkor visszanyúl az élő DataSet megfelelő táblá- 
jához, és onnan veszi az adatokat. Olyannyira élő ez a kapcso- 
lat, hogy a DataSet bármilyen változása azonnal látható az 
XmiDataDocument-en keresztül, sőt, visszafelé is megy a kap- 
csolat, tehát ha az xml interfészen keresztül módosítunk vala- 
mit, az tulajdonképpen a DataSet módosítást jelenti! 

Az egész mágia kulcsa az a jól megtervezett XmlIReader, XmlWri- 
ter architektúra, amiről négy résszel ezelőtt kezdtünk el beszél- 
ni. Mivel a legelemibb író-olvasó funkcionalitáshoz szükséges 
metódusokat a két absztrakt alaposztály írja elő, ezért gyakor- 
latilag bármilyen adatforráshoz lehet írni olyan elérő osztályt, 
amelyen keresztül az adatok xml InfoSet-ként látszanak, azaz 
elemeken és attribútumokon keresztül. Mivel a bejáráshoz szük- 
séges alapvető metódusokat és jellemzőket minden xml forrás- 
ként viselkedni akaró osztály kénytelen implementálni az alap- 
osztályok által rákényszerített módon, ezért bármely xml-t fel- 
dolgozó osztály (pl. XslTransform) képes használni a leszármaz- 
tatott xml osztályokat, hisz mindig csak az alaposztályok metó- 
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dusait hívják, de azok mindig a konkrét megvalósító osztály me- 
tódusait érik el (mert az alaposztály metódusai virtuálisak). 

Az msdn-ben [2] publikáltak egy cikket, amiben leírják hogy kell 
nem xml adatforrásokat xml-ként (InfoSet-ként) láttatni. Ott pél- 
dául a fájlrendszerhez írtak egy elérőosztályt, amelyen keresztül 
xml doksiként láthatóak a fájlok, könyvtárak és azok jellemzői. Az 
. . XmiDataDocument pont az ott leírt módon működik, azzal a hoz- 
záadott plusszal, hogy figyeli a DataSet változásait is. Ehhez a 
DataSet-beli DataTablek változásait jelző eseményeket kapja el 
(RowChanged, RowDeleted, stb.). Mindezen háttérinformációk nin- 
csenek részletesen dokumentálva, azonban az Anakrino [3] nevű 
IL-ről Ctt-ra decompiler sokat segít a részletek megértésében :) 
Lássuk hát működés közben ezt a csodaosztályt! Induljunk ki az 
előző példában összerakott, egymásba ágyazott elemeket tartal- 
mazó DataSet-ből. Erre szeretnénk , ráhúzni" egy XmIDataDocu- 
ment-et. Ez nagyon egyszerű lesz: 


XmliDataDocument xd - new XmlDataDocument(ds) 


Azaz a konstruktorban átadunk egy feltöltött DataSet referen- 
ciát, és máris megtörtént a szinkronizáció a két osztály között. 
Győződjünk meg erről, például úgy, hogy lefuttatunk egy XPath 
lekérdezést a kapott virtuális xml dokumentumon. 

Ez a látszólag triviális feladat eléggé csúnya kinézetet fog kap- 
ni. A probléma forrása az, hogy a TermekKatalogus gyökérele- 
men van egy default névtér deklaráció: 


cKTermekKatalogus 
xmlnsz"http://tempuri.org/TermKat.xsd"2 


Azaz a dokumentumban az összes elem a fenti URL-rel azonosított 
névtérhez tartozik. Mivel eddig nem csináltunk semmit a DataSet 
xml kimenetével, ez nem zavart minket, most azonban úgy kell 
megfogalmaznunk az XPath kifejezéseinket, hogy a végrehajtó 
tudja, hogy mi erre a névtérre vonatkoztatjuk a kérésünket. 

Az összes termékkategóriát így kérhetnénk le, ha nem lenne ez 
a névtérdeklaráció: 


/TermekKatalogus/Categories/CategoryName/text( ) 


Ugye milyen egyszerű lenne így az élet? A lekérdezést így po- 
fonegyszerű lenne végrehajtani: 


XmliNodeList n - xd.SelectNodes( 
4 "/TermekKatalogus/Categories/ 
4. CategoryNameztext( )"); 


Azonban ez azt jelenti, hogy a null névtérben található elemek- 
re építettünk egy lekérdezést. Ez működne, ha nem lenne a 
default névtérdeklaráció a doksi elején. 

Így viszont egy bonyolultabb megoldást kell választanunk. Va- 
lahogyan létre kell hozzunk egy általunk megálmodott prefixszel 
rövidített névtér deklarációt pontosan arra az URL-re, amihez a 
default névteret lerögzítette a DataSet. Koncepcionálisan (de 
nem a valóságban) valahogy így nézne ez ki: 


cKTermekKatalogus 
xmlnsz"http://tempuri.org/TermKkat.xsd" 
xmlns:sajatprefix-"http://tempuri.org 
9 /Termkat.xsd"2 
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Azaz ugyanarra a névtérre mint ami a default névtér 
létrehozunk egy prefixet is, így a prefixen keresztül 
már explicit ki tudjuk jelölni az XPath-ban alkalma- 
zott elemek befoglaló névterét: 


/sajatprefix:TermekKatalogus/sajatprefix: 
4 Categories/sajatprefix:CategoryName/text() 


Ez már rendben lesz, a kérdés az, hogy hogyan lehet utólag név- 
térdeklarációt létrehozni? 

Az XmIDataDocument SelectNodes() metódusának van olyan vál- 
tozata is, amely második paraméterként egy XmlNamespaceMa- 
nager osztályt vár el. Ez az az osztály a frameworkben, ami a 
névterek kezelésére szolgál. Nézzük meg a létrehozását: 


XmlNamespaceManager nsmgr - 
new XmlNamespacelanager(xd.NameTable); 


A konstruktorban át kell adjunk egy NameTable osztályreferen- 
ciát, amelyet az XmIDataDocument példányunktól kértünk el. 
Miért kellett ezt így megbonyolítani, miért kell ezzel az osz- 
tállyal is foglalkoznunk? 

A .NET-es xml osztályok nagyon ki vannak élezve arra, hogy minél ke- 
vesebb memóriát használjanak, és minél gyorsabb legyen a működé- 
sük. Ezért a háttérben különböző optimalizálási technikákat vetnek 
be, és ezek miatt időnként bonyolultabb használni egyes funkciókat. 
A NameTable egy xml dokumentumban (XmlDocument, XmlReader, 
XmiDataDocument, ...) található elem - és attribútumneveket tartal- 
mazza táblázatos formában. Amikor a beolvasás során a forrásdoku- 
mentumban találnak egy új nevet, akkor azt berakják egy NameTab- 
le-be. Ha ezek után újra előfordul ugyanaz a név (ami igen valószí- 
nű az ismétlődő adatok miatt) , akkor nem foglal le neki helyet a be- 
foglaló osztály, csak egy referenciával rámutat a NameTable megfe- 
lelő bejegyzésére. Azaz a különböző neveket mindig csak egyszer tá- 
rolják le, s ezzel jelentős mennyiségű memória spórolható meg. 

De ez csak a dolog egyik fele. Ez jelentős sebességnövekedéssel 
is jár a beolvasott doksi feldolgozásakor, mert például két elem 
összehasonlításakor nem kell tényleges szövegösszehasonlítást 
végezni (ami mint tudjuk költséges), hanem elég csak a Name- 
Table-be mutató referenciákat összevetni. Ha egyeznek, a két 
elem (attribútum) neve azonos. 

A NameTable osztályt decompilerrel átvizsgálva megfigyelhető, 
hogy a neveket egy tömbben tárolja. Minden stringhez egy hash 
értéket képez, amely a stringgel együtt tárolódik. Az azonos 
hash-ű elemek pluszban össze vannak láncolva, így egy string ke- 
resésekor a hash kiszámítása után már csak az elemek töredékén 
kell végigmennie a keresett string létezésének megállapításához. 
Ez a hash-elős buli ugyan 
némi plusz memória fel- 
használással jár, de cseré- 
be nagyon gyorsak lesz- 
nek az xml osztályok. 
Ezeknek a finomságok- 
nak örülünk, de általá- 
ban nem használjuk őket 
tudatosan: elég hogy a 
háttérben így működnek. 
Most már ismerjük a 
NameTable működését, itt az ideje használni is azt. Az XmlNames- 
paceManager a konstruktorában kapott egy referenciát az xml do- 
kumentumunk NameTable-jére. Ezzel itt még nem túl sok mindent 
csinál, csak hozzáad egy-két, a névterek kezeléséhez szükséges 
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stringet. Ha szeretnénk új prefixeket és névtereket 

használni a lekérdezésekben, akkor az AddNamespa- 

ce() metódust kell használnunk. Az első paraméter a 
prefix neve, a második a névtér teljes URN-je: 


nsmgr . AddNamespace ( "alapnevter" , 
"http://tempuri.org/TermKkat .xsd" ) ; 


Ez hozzáadja a prefix és URN azonosítókat a használni kívánt do- 
kumentum NameTable-jéhez, és ő maga is lejegyzi (egy saját ve- 
remben), az összetartozó párost. 

És végre beérik munkánk gyümölcse, mehet a lekérdezés: 


XmiNodeList n - xd.SelectNodes( 
" /alapnevter : TermekKkatalogus/alapnevter : Categories 
/alapnevter : CategoryName/text()", nsmgr); 


Látjuk, hogy második paraméterként átadjuk a névtérmenedzse- 
rünket a SelectNodes()-nak, aki most már ismeri az XPath kife- 
jezésben használt ,alapnevter" prefixet. 

A metódus visszatérési értéke a kiválasztott node-ok listája, 
amit bejárhatunk egy ciklusban: 


IEnumerator i - n.GetEnumerator( ) ; 
while (i.MoveNext()) 
( 
XmlText t - (XmlText)i.Current; 
Console.WriteLine(t.Value); 


Azért kasztoltam bátran az általános XmlNode-ot XmlText-re, 
mert az XPath kifejezésemben tényleg text node-okat válogat- 
tam le (az elemek szöveges tartalmát). 

Valójában az egész névteres problémát kikerülhettük volna, ha a 
DataSet mögötti séma targetNamespace attribútumát átírtuk vol- 
na üres stringre. Ha a kapott xml dokumentumot (web-es megje- 
lenítéshez) azonnal áttranszformáljuk HTML-é, akkor ez rendben 
is van. Ha azonban a kimenetet szeretnénk más számára elkülde- 
ni (B28B felhasználás) , akkor mindenképpen adjunk egy értelmes 
névtérazonosítót, és ne használjuk üres névtereket. 


Arcra fel! 

Remélem az előbbi névtérmizériával nem vettem el senki kedvét 
a névterektől, de sajnos egyszer meg kell birkózni velük, aztán 
már nem annyira fájdalmasak. 

Zárásul nézzük meg azt, amire a legtöbben fogják használni az 
XmiDataDocument-et: XSL transzformáció forrásául. Mivel az 
XmiDataDocument támogatja az IXPathNavigable interfészt, ezért 
nyugodtan szerepelhet az XslTransform osztály xml forrásaként. 
Mi ebben a szenzációs? Az, hogy az adatok az adatbáziskiszol- 
gálótól az adatbázis saját (általában nagyon tömör) protokoll- 
ján jönnek át a DataSet-be, majd az XmIDataDocument képes 
ezt úgy átnyújtani a transzformáló osztálynak, hogy közben se- 
hol nem alakul át a tartalom xml szöveggé! Végig xml-lel dolgo- 
zunk, de sehol egy kacsacsőr a feldolgozási láncban! Ennél ha- 
tékonyabb xml feldolgozást nehéz elképzelni. 
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Ha például weblapban gondolkodunk, akkor a webkiszolgáló és az 
adatbázis közötti kommunikáció a lehető leghatékonyabb, és még 
a weblapban sem kell oda-vissza alakítgatni az xml szövegeket. Ez 
gyökeresen ellentétes azzal, amikor például SOL Server-rel xml ki- 
menetet generáltatunk (kacsacsőr, redundancia megjelenik) , ezt a 
weblapban azonnal értelmeztetjük egy xml parserrel (kacsacsőr 
leesik), és abból transzformálunk. Vajon melyik a gyorsabb? 
Mielőtt valaki azt a következtetést vonná le ezen információk is- 
meretében, hogy az SOL Server xml támogatása értelmetlen, áll- 
jon itt néhány tény: 

6 az SOL Server OLEDB providere képes arra, hogy egy XML ki- 
menetű lekérdezést az eredeti formájában (közönséges sgl pa- 
rancsként) hajtassa végre az SOL Serverrel, az SOL Server sa- 
ját protokollján lehozza a lekérdezés kimenetét mint hagyo- 
mányos eredményhalmazt, és ügyféloldalon maga a provider 
alakítja ezt át xml-é. Ez a , Client Side XML" lehetőség. 

A közvetlen xml kimenet (különösen webszerveren keresztül) 
akkor jön nagyon jól, ha az SOL Serverből más rendszerek 
akarnak lekérdezni xml adatokat. Ilyenkor nem kell semmi- 
féle átjátszóalkalmazás, csak ki kell használni az SOL Server 
beépített lehetőségeit. (Az SOLXML .NET-beli programozásá- 
val hamarosan foglalkozunk sorozatunkban. ) 

Maga a transzformáció teljesen azonos azzal, amit a kettővel 
ezelőtti számunkban már áttekintettünk, csak most nem XPath- 
Document vagy XmilDocument a forrásunk, hanem az előbbi 
XmiDataDocument: 


XsiTransform xsl - new XslTransform( ); 
xs1l.Load(e"..VN..Mtrafo.xsl"); 

Streamlriter sw - new StreamWriter("ki.html"); 
xs1l.Transform(xd, null, sw); 

sw.Close(); 


A korábbi névtér okozta galiba végigkíséri az xslt-t is, a részle- 
tekért érdemes megnézni a példaalkalmazást az [1] címen. 


Zárszó 

A következő hónapokban egy picit szüneteltetjük a .NET xml osz- 
tályait, és előveszünk egy-két xml alapszabványt, például az xml 
sémát, és azokat fogjuk boncolgatni. A .NET-es xml osztályokban 
sokkal több lehetőség rejlik, mint amennyit ebben a négy rész- 
ben be tudtam mutatni, úgyhogy még elő fog kerülni a téma. 


Soczó Zsolt 
Zsolt.Soczo 2onetacademia.net 
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[1]: A cikkben szereplő példakódok 
http://technet.netacademia.net/download/xml 

[2]: Implementing XmlReader Classes for Non-XML 

Data Structures and Formats 
http://msdn.microsoft.com/library/default.asp?url-/library 
/en-us/dndotnet/html/Custxmlread.asp?frame-true 

[3]: Anakrino Download 
http://www.saurik.com/net/exemplar 
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Microsoft 


Exchange 2000 


Méltatlanul elfeledett termékre térünk vissza: az Exchange Serverre. 

Nem a felhasználók feledték el, hanem mi nem törődtünk vele ezidáig megfelelően. 
Most útjára indítjuk Exchange Server sorozatunkat, mely a telepítéstől kezdve 
végigvezet a termék használatának rejtelmein. 


Nem hiszem, hogy ezt a cikket az Exchange 2000 bemutatásával 
kellene kezdeni, nem fogom leírni az Exchange 5.5 utáni újítá- 
sokat sem, mert nem hiszem, hogy az olvasó soha nem hallott 
még - a Microsoft termékpalettáján csak Exchange néven isme- 
retes - üzenetkezelő és csoportmunka-támogató alkalmazásról. 
Ha mégis így volna, a tech.net magazin 2000. évi .NET különszá- 
mában található összefoglaló termékleírást, valamint a Microsoft 
weboldalain is - akár magyar nyelven is - fellelhető áttekintő is- 
mertetőt tudom ajánlani, Ne feledjük, hogy a tech.net hasábjain 
többször volt már szó az Exchange 2000 egyes kiragadott részei- 
ről, többször fogok utalni ezekre a cikkekre a későbbiekben. 
Kezdjük a cikket gyakorlatias, a telepítés szempontjából fontos 
ismeretekkel. Sok olyan tulajdonsága van a terméknek, amelyet 
már a telepítés megkezdése előtt fontos tudni. A termékben rej- 
lő lehetőségeket, és azok bővebb ismertetését inkább részletek- 
ben, mindig az adott területre koncentrálva említem. 


Az Exchange 2000 pillérei 

Az Exchange 2000 négy alapkőre építkezik. Ezek az Active 
Directory, a System Attendant, az Information Store, és az 
SMTP. A sorrend nem fontossági: bármely elem hiányzik, vagy 
nem működik ezek közül, az Exchange működésképtelenné vá- 
lik. Nézzük röviden, mit is takarnak a fenti elemek. 


System Attendant 

A rendszer szolgája - röviden SA - természetesen szolgáltatás- 
ként fut az Exchange kiszolgálón, és rengeteg dolga van. Leg- 
több feladata összefügg az Active Directoryval, általa léteznek 
és frissülnek a címlisták (Address Lists), ideértve az , offline" 
címlistát is, rajta keresztül történnek az Exchangeből történő 
AD lekérdezések, továbbá az Exchange útválasztó tábláinak lét- 
rehozása, karbantartása is az ő feladata. Odafigyel a többi 
Exchange szolgáltatásra is, ha ő nem működik, akkor a többi 
szolgáltatás sem: utoljára áll le, és az elsők közt indul. 

Tavalyi, 2001/7. számunkban megtalálható minden, amit erről a szol- 
gáltatásról tudni érdemes. Mindenképp ajánlott olvasmány, ha valaki 
még nem olvasta volna. 


Information Store Service 

Az Exchange 2000-ben kétféle adatbázissal találkozunk. Az egyik a 
régről ismert .edb kiterjesztésű Rich Text tároló, ahova a hagyomá- 
nyos MAPI-s hozzáférés (mikor az Outlookot használjuk) esetén ke- 
rülnek az adatok, valamint van egy új ún. streaming adatbázis, 
amely azokat az adatokat tartalmazza, amelyek nem MAPI haszná- 
lat során (jó példa az Outlook Web Access) kerülnek az adatbázisba 
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Az adatok típusa szerint megkülönböztetjük a , Private Store"-t, 
és a , Public Store-t". Az első a felhasználói levelesládákat, a má- 
sik a nyilvános mappákat tartalmazza. Ez a legegyszerűbb eset- 
ben is összesen négy adatbázisfájlt jelent (két-két .edb és .stm). 
Az Information Store Service a nevében hordozza a feladatát: ez 
az Exchange adatbázisait irányító szolgáltatás. (Nem összekeve- 
rendő az IIS-el, az Internet Information Services-el!) Egy későbbi 
cikkben részletesen lesz szó az Exchangehez tartozó adatbázisok- 
ról, most elég tudni azt, hogy milyen típusok léteznek. 


SMTP 

Teljes nevén Simple Mail Transfer Protocol: az Exchange 2000 üze- 
tettovábbító rendszerének alapja. Az előző verziókban is jelen volt 
már, de akkor az MTA (Message Transfer Agent) volt felelős a bel- 
ső üzenettovábbításért, az útválasztó folyamat meghatározásáért; 
az utólag telepített IMS (Internet Mail Service) biztosította az 
SMTP alapú levelezést a 
külvilággal. Az Exchange 
2000-ben már SMTP dol- 
gozik az összes üzenet 
továbbításán és az útvá- 
lasztás is az ő feladata. 
Nincs MTA többé, nincs 
IMS, csak SMTP. 

Jó cikk található az 
SMTP-ről a  tech.net 
2001. áprilisi számában. 
amely a NetAcademia weblapján, az [1] címen is megtalálható. 


és az SMTP. 


A kétezresek integrációja 

Az Exchange szóban forgó verziója Windows 2000 környezetben 
működőképes csupán, mivel sok helyen és minden szinten beépül 
környezetébe. Legszembetűnőbb talán az Active Directoryval 
való integráció. 

Az Exchange 2000 olyannyira beépül a Windows 2000 Active 
Directoryba, hogy nem is bír nélküle működni: alapfeltétel az AD 
megléte az Exchange telepítéshez. Az Exchange 5.5-nek még 
saját, különbejáratú címtáradatbázisa volt. Ennek helyét az 
Exchange 2000-ben teljes egészében a Windows 2000 Active 
Directory vette át. Az Exchangeről minden az Active 
Directoryban van nyilvántartva: itt vannak a felhasználók, a név- 
jegyek, a disztribúciós listák (olyan csoportok, amelyekhez e-mail 
cím is tartozik), valamint az Active Directory szolgáltatja a 
munkaállomások felé a címlistákat is. 

Ezeken kívül az Exchange összes beállítása is a címtárban, 
közelebbről a Configuration névtérben tárolódik. Amikor a legelső 
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alapkőre építkezik. Ezek 
az Active Directory, 

a System Attendant, 
az Information Store, 
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A levelek hitelesítéséhez 
és titkosításához a Key 
Management Server 
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Exchange 2000 telepítésre kerül, az Exchange kibőví- 
ú ti az Active Directory sémáját. (Emlékeztetőül, a séma 
p / az AD azon része, amelyben az összes objektum (fel- 
— használók, számítógépek, csoportok, stb.) definíciója, le- 
hetséges tulajdonságai vannak leírva. ) 
A Windows 2000 szolgáltatásai közül nemcsak az Active 
Directory szükséges az Exchange 2000 működéséhez, hanem egy 
sor egyéb alapszolgáltatás is Windows 2000 alapokon nyugszik. 
Nézzük csak sorban. 
Az Exchange" 2000 biztonsági rendszere is a Windows 2000 infra- 
struktúrán alapszik. Mielőtt a felhasználók használhatnák az Ex- 
changet, a Windows 2000-ben a felhasználói nevükkel és jelszavuk- 
kal azonosítani kell magukat. Csak valódi AD felhasználóknak lehet 
levelesládájuk az Exchange 2000-ben: külső fiók legfeljebb e-mail 
címmel rendelkezhet, tárolóhellyel nem. Ha valaki egyszer beje- 
lentkezett, akkor az Exchange használatához már nem kell újra azo- 
nosítania magát, nincs újabb authentikációs kör. Az AD-ban tá- 
rolódnak az Exchange jogosultságok is (gondolok itt az egyes mail- 
boxokhoz tartotó felhasználói jogokra: ki tudja megnyitni az adott 
mailboxot és ki nem) , vagy az Exchange rendszergazdai jogosultsá- 
gokra, amelyekkel jól meghatározható, hogy melyik rendszergazda 
mely területeken garázdálkodhat. A biztonság témakörébe tartozik 
az üzenetek titkosítása is, bár ezt alapbeállításokkal nem használ- 
ja az Exchange 2000, de a lehetősége megvan. Ezekhez szintén a 
Windows 2000 szolgáltatások adják az alapot, gondoljunk pl. az 
Ipsec-re. A levelek hitelesítéséhez és titkosításához a Key 
Management Server használatos, amely ugyan az Exchange része, 
azonban a hozzá szükséges bizonyítványok és kulcsok a Windows 
2000 egy eleméből, a Certificate Services-ből is előállíthatók. Egy 
újabb pont az összefonódásra. 
Ezen kívül ott vannak a Windows 2000 Internet Information Services 
(IIS) komponensei is. Az IIS azáltal, hogy egy sor - Interneten hasz- 
nálatos - protokoll használatát támogatja, lehetővé teszi, hogy az 
ügyfelek ne csak MAPI-n ke- 
resztül, mondjuk Outlookból 
tudják elérni üzeneteiket, 
hanem például POP3-mal, 
vagy IMAP4-gyel is - vagy 
akár HTTP-n keresztül. Az 
üzenetforgalmat biztosító 
SMTP és NNTP szolgáltatás is 
az IIS része. Az NNTP-t azért emelném ki, mert az alapból nem tele- 
pül az IIS-sel: ezt bizony külön fel kell rakni! Ne feledkezzünk meg a 
Windows 2000 Active Directory működéséhez nélkülözhetetlen DNS 
szolgáltatásról sem. Természetesen az Exchange 2000 is DNS-t hasz- 
nál névfeloldáshoz, bár az nem feltétel, hogy a DNS szolgáltatást 
Windows 2000 kiszolgáló adja. 
Miért is jó ez a nagy összefonódás a két termék közt? Gondoljuk 
végig! A közös címtár egyszerűbb felügyeletet tesz lehetővé, 
ráadásul az ehhez szükséges eszközök összehozhatók egy jól 
kialakított MMC konzolba. A jogosultságok egységes kezelése 
szintén megkönnyíthetik a rendszergazdák dolgát. Például a 
Windows 2000 csoportokat a jogosultságok kezelése mellett 
használhatjuk disztribúciós célokra is. Az Exchange és az AD rep- 
likációja is teljesen összefonódott. Az előző verziókban az 
Exchange beállításainak, változásainak replikációja objektumala- 
pú volt, az AD replikáció viszont tulajdonság (attribútum) alapú, 
így kisebb a replikációval kapcsolatos hálózati forgalom. 
Általában elmondható, ha valamit csak egyszer, egy helyen kell 
beállítani, és azt mind a két rendszer használni tudja, nagy 
előny mindkét félnek, bár a nagy egymásrautaltság azt is jelen- 
ti, hogy egyik sem tud a másik nélkül teljesértékűen működni - 
ez leginkább úgy igaz, hogy az Exchange 2000 nincs Windows 


használatos 
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2000 nélkül, viszont a Windows 2000 vígan boldogul az 

Exchange 2000 nélkül... 

Az alábbiakban összefoglaltam, milyen módon fonódik össze a 

Windows 2000 és az Exchange 2000: 

Az Active Directory szolgáltatja a címlistákat az ügyfeleknek 

Az Exchange teljes nyilvántartása, beállításai az AD-ban tá- 

rolódnak 

"8 Az Exchange a Windows 2000 SMTP, NNTP, HTTP szolgálta- 
tásait használja 

8 Akárcsak a Windows 2000, az Exchange is a DNS-t használ- 
ja névfeloldásra. 
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Pár szóban az ügyfelekről 

Sokféle ügyfélprogramot, és hálózati protokollt használhatunk az 
Exchange adatbázisokban levő adatok elérésére. Most csak röviden 
szólnék ezekről a lehetőségekről, a sorozatban egy egész cikket 
szentelünk majd ennek a témának. Közelítsük a dolgot most a kom- 
munikációra használt protokollok oldaláról. Ezek szerint a követke- 
zőket tudjuk Exchange 2000-rel használni. 


MAPI (Messaging Application Programming Interface) - ez egy 
redmondi fejlesztésű, elég régi protokoll, már az előző Exchange 
verziók is ezt használták az ügyfelek és a kiszolgáló közti kommu- 
nikációra. Pl. az Outlook vállalati vagy munkacsoport (Corporate 
or Workgroup) telepítésével használjuk ezt a protokollt. Öregecske 
kecske, de mind a mai napig a MAPI az egyetlen teljeskörű szol- 
gáltatást nyújtó protokoll az Exchange választékában. 


POP3 (Post Office Protocol v3) - ennek segítségével csak letöl- 
tögetni tudjuk a leveleket egy Exchange kiszolgálóról, levélkül- 
désre ez esetben az SMTP-t használjuk. Nagyjából minden leve- 
lező ügyfél támogatja ezt a fajta kommunikációt. (Az Outlook 
Internet módban telepítve, vagy az Outlook Expressz, Netscape, 
Eudora, PMail, Pine, stb.). Levelesládánk sok-sok ügyes mappá- 
ja közül egyes egyedül az Inboxot éri el. 


IMAP4 (Internet Message Access Protocol) - akárcsak a POP3, az 
IMAP is csak egyirányú kommunikációra képes, bár azt másként te- 
szi, pl. egyszerre több mappát tud kezelni, míg a POP3 csak egyet. 
A legtöbb levelezésre használt ügyfél program támogatja. Ezzel már 
el lehet érni a kiszolgálón lévő összes mappát, de valamennyit e- 
mail tárolónak érzékeli az IMAP4 ügyfél - a naptár és a névjegyek 
egészen vicces látványt nyújt ilyen szemüvegen keresztül szemlélve. 


NNTP (Network News Transfer Protocol) - ez is egyirányba viszi 
csak az üzeneteket, ez a protokoll használatos a hírcsoportok 
(newsgroupok) olvasgatására. Az kiszolgálóoldalon az Exchange 
2000 tud NNTP kiszolgáló lenni, míg az Outlook Express vagy az 
Outlook Internetes telepítése is tud NNTP ügyfél lenni - de ter- 
mészetesen van egy rakás hírolvasgató program is forgalomban. 


SMTP (Simple Mail Transfer Protocol) - ha az előző három proto- 
kollt használjuk a levelek lehúzogatására, akkor az SMTP-t kell 
használni arra, hogy mi is tudjunk válaszolni. Nemcsak ügyfél és 
kiszolgáló közt megy a levelezés SMTP-vel, hanem a levelező ki- 
szolgálók egymással is SMTP-vel, illetve annak egy fejlesztett 
változatával, ESMTP-vel kommunikálnak. 


HTTP - tipikus példa erre az Outlook Web Access segítségével 
történő levelezés. Amikor mi egy böngészőből kapcsolódunk az 
OWA-n keresztül az Exchange kiszolgálóhoz, akkor HTTP, vagy 
sokszor titkosítva, HTTPS protokollon megy a kommunikáció 
ügyfél és kiszolgáló közt. 
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LDAP - (Lightweight Directory Access Protocol) az Exchange en- 
nek segítségével kapcsolódik az Active Directoryhoz. Az ügyfelek 
ugyancsak LDAP-pal kapják meg a címlistát, amikor Outlookot 
(Internet telepítésben), vagy Outlook Expresst használunk. A 
Netscape levelezőprogramja is képes LDAP-ot használni. 


EXIFS (Exchange Installable File System) - ez a , protokoll" MS fejlesz- 
tés, ennek segítségével úgy tudjuk elérni 
az adatokat az Exchange kiszolgálón, 
mintha az egy fájlkiszolgáló lenne; pél- 
dául közvetlenül a Wordből tudunk doksit 
az Exchange adatbázisba menteni. 


Melyik Exchange jó nekünk? 

Miért, olyan sokféle van? Az Exchange 
2000-ből három változat kapható, 
hogy mindenki megtalálhassa a pénztárcájának és igényeinek 
leginkább megfelelő kiszerelést. 


Microsoft Exchange 2000 Server (ES) 

Olyan esetben érdemes ezt a terméket választani, ha megelég- 
szünk azzal, hogy egyetlen logikai tárolóban (Store), maximum 
16Gb-nyi adatot tudunk használni. Ezzel a változattal nem tu- 
dunk elosztott (Front-end/Back-end) konfigurációt megvalósíta- 
ni, Chat kiszolgálót építeni, és nem tudjuk fürtön sem használ- 
ni. Nincs benne X.400 csatoló sem. Hát akkor mit lehet, mi van? 
Az alábbi táblázat segít ebben: 
































Funkció ES ES SZBES 
AD integráció van — van 

Web Storage rendszer van — van 
Instant Messaging van — van 

POP3, IMAP4, SMTP, NNTP van van 

HTTP OWA van — van 
MSMail, cc:Mail, Notes/Domino, van — van 
GroupWise csatolók 

Chat van 

X.400 csatoló van 
Front-end/Back-end támogatás van 
Korlátlan adatbázis méret van 

Több Store egy kiszolgálón van 
Windows Clustering van 
Conferencing van 


Microsoft Exchange 2000 Enterprise Server (EES) 

Olyan helyeken érdemes használni, ahol - mondjuk - fürtöt szeret- 
nénk építeni, vagy ahol szeretnénk elkülöníteni funkciókat egymás- 
tól, esetleg nem elég 16GB az Exchange adatbázisoknak, illetve ahol 
több független adatbáziscsoportot (Store) szeretnénk létrehozni. 


Microsoft Exchange 2000 Conferencing Server (ECS) 

Egyetlen, de összetett funkciója van, az adat-, hang- és vi- 
deokonferencia-szolgáltatás. Az Exchange másik két típusával 
együttműködve képes mindezt megvalósítani. Multimédiás kon- 
ferencia szolgáltatáshoz ügyfélprogramként NetMeetinget 
használunk, ami természetesen jár hozzá. (Tudta-e, hogy a 
NetMeeting és a Terminal Services ügyfélprogram ugyanarra a 
T.120-as protokollcsaládra építkezik? Bizony, rokonok. ) 


A telepítés előkészítése 

Van néhány alapvető tulajdonság amelyet nem tudunk áthágni. 
Először is, egy Active Directory erdőben (forestben) csak egy 
Exchange szervezet (organization) létezhet. Csak egy, nem több. 
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Tartsuk ezt mindig szem előtt! 
Másodszor, csak olyan Windows 2000 kiszolgálóra tu- 
dunk Exchanget telepíteni, amelyik egy Active 
Directory része. Elég ha csak tag a tartományban, nem 
kell tartományvezérlőnek lennie, de annak sincs semmi akadá- 
lya, hogy DC-re telepítsük az Exchange szolgáltatást. 
Az IIS megléte az adott gépen szintén feltétele az Exchange te- 
lepítésnek; az SMTP és az NNTP is tele- 
pítve kell legyen az alapszolgáltatások 
mellett. Az Exchange telepítéskor fel- 
turbózza az IIS-ben fellelhető SMTP és 
HTTP szolgáltatást, valamint a POP3 és 
az IMAP4 protokollt hozzáadja az IIS- 
ez. 
A leendő Exchange kiszolgálóra a tele- 
pítés előtt minimum az első Service 
Packot fel kell rakni, javaslom azonban inkább rögtön az SP2-t! 
A telepítés elbukhat, ha a DNS illetve maga az Active Directory 
nem működik hibátlanul, ezért érdemes a DNS és az AD működé- 
sét ellenőrizni. A Windows 2000 Support Tools csomagban talál- 
ható NLTEST segítségével ugyanazokat ellenőrizhetjük az AD és a 
DNS működéséről, amit majd a telepítés során az Exchange is 
megtesz, ugyanazokkal az API hívásokkal: 
3 kapcsolóját is érdemes használni. Futassuk az nltest progra- 
mot a leendő Exchange kiszolgálóról. 
Először: 


ar 


Cc:Y53nltest /dsgetsite 
Default-First-Site-Name 
The conmand completed successfully 


o A Site ellenőrzése 


Ha a fenti parancs valami hibát ad, akkor érdemes körülnézni a 
telephely (site) és a hozzá tartozó alhálózatok (subnet) beállí- 
tásainál az AD Sites and Servicesben. 

Másodszor: futtassuk az nltest /dsgetdc:cdomain névz paran- 
csot, például így: 


c:NVnitest /dsgetdc:heTT 
pc: XDc1 
Address: M10.10.10.10 
Dom Guid: b2454a7c-ff69-4dfc-8fb0O-4f94404a8770 
DOm Name: HELL 
Forest Name: hell.net 
Dc Site Name: Default-First-Site-Name 
Our Site Name: Default-First-Site-Name 
Flags: PDC GC DS LDAP KDC TIMESERV 
WRITABLE DNS. FOREST CLOSE SITE 
The command completed successfully 


o A domain és a forest ellenőrzése 


Ezzel vagy a legközelebbi tartományvezérlőről kapunk informá- 
ciókat, vagy ha történetesen maga a gép tarományvezérlő, ak- 
kor arról fognak megjelenni az adatok. A Flags kezdetű sor ta- 
lán a legérdekesebb, abban van leírva az adott gép összes tar- 
tománybeli funkciója. Könnyen ki lehet találni mi mit is jelent. 
Végül érdemes az nitest /dclist:-domain név: parancsot is fut- 
tatni, ami visszaadja a megadott tartomány összes vezérlőjének 
nevét, valahogy így: 


c:Nnltest /dclist:heli1 

Get list of Dcs in domain "hell" from "VDC1". 
pc1.hel1.net [Poc] [DS] site: Default-First-Site-Name 
The command completed successfully 


5 A tartományvezérlők listája 
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Ezen kívül használhatjuk az nslookup-ot is a DNS 
helyes működésének tesztelésére, az SRV bejegyzé- 
sek ellenőrzésére. 
Ha igaz az, hogy a hibák 13090-a a DNS-ben keresen- 
dő, és mi a fenti parancsok használata során nem kapunk 
vissza hibaüzeneteket, akkor szinte biztosak lehetünk benne, 
hogy a telepítő nem fog elbukni DNS vagy az AD nem megfelelő 
működése miatt. 


Telepítés 
Vegyük azt az egyszerű esetet, hogy van egy Windows 2000 
Active Directory környezetünk, még soha nem használtunk Ex- 
changet, de most úgy döntünk, erre van nekünk szükségünk, és 
telepítjük a tartomány egy gépére. (Persze a legtöbb esetben az 
Exchange 5.5 migrációja okoz nagy fejtörést, bár maga a telepí- 
tés akkor is igen hasonló: több lépésből áll, némileg bonyolítja a 
helyzetet az Active Directory Connector, amely arra való, hogy az 
Exchange 5.5 Directory információkat összehozzuk az Active 
Directoryval. ) 
Még mindig nem ugorhatunk neki a setup.exe-nek, mert előtte 
fel kell készíteni az AD-t arra, hogy be tudja fogadni az Exchan- 
ge sajátos bejegyzéseit. Mit jelent ez? Bár az Exchange 2000 
teljesen integrált az AD-ba, ugyanakkor az AD helyből nem ren- 
delkezik minden objektummal ami kell az Exchangehez; egyes 
objektumok léteznek ugyan, de kevesebb tulajdonsággal rendel- 
keznek, mint kellene. Ahhoz, hogy az Exchange otthon érezze 
magát, elő kell készíteni az AD sémát, és még pár apróságot is 
el kell követni. Ehhez tudjuk használni a setup.exe /forestprep 
és /domainprep kapcsolóját. 

A tech.net magazin 2001/5. számában egy egész cikk szól arról, 

mit hogy csinálnak a fenti parancsok, mikor kell és mikor nem kell 

használni őket. Ez a cikk a [2] címen is megtalálható. 

Most csak annyit, hogy ezeket külön kell futtatni a telepítés 

előtt, vagy - bizonyos esetekben - maga a telepítés megcsinál- 

ja a szükséges AD módosításokat. 

Az első Exchange 2000 kiszolgáló telepítéséhez a következő jo- 

gokkal rendelkező felhasználói fiók szükségeltetik: 

"2 A leendő Exchange kiszolgálón az Administrators csoport tag- 
ja legyen (ne feledjük, hogy a Domain Admins csoport hely- 
ből tagja a helyi Administrators csoportnak) 

"8 Exchange Full Administrator szerepkörrel rendelkező account 
legyen - ez a leghatalmasabb szerep ami létezik Exchange 
vonatkozásában, és a forestprep során lehet meghatározni 
ezt az felhasználót vagy csoportot. Értelemszerűen, ha fo- 
restprep során felhasználót adtunk meg akkor annak nevé- 
ben kell belépni a telepítés előtt, ha csoportot adtunk meg, 
akkor ennek a csoportnak legyen tagja az a felhasználó, aki- 
nek nevében futtatjuk a telepítőt. 

Ha mindent jól előkészítettünk, akkor maga a telepítő varázsló 

nem kérdez sokat, nagyjából annyit, hogy mely összetevőket és 

hova szeretnénk telepíteni. 
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5 A összetevők közt itt válogathatunk 


Érdemes néhány szót ejteni arról, mi történik a háttérben, ami- 

kor a bitkolbászok meg-megtorpanva növögetnek. 

A telepítőnek négy jól elkülöníthető szakasza van. 

1. Az első, amikor a rendszergazda kiválogatja, mit is szeretne 
telepíteni: ez tulajdonképpen a varázsló futtatása. Megjegy- 
zem, hogy mielőtt válogathatunk az összetevők közt, elvé- 
gez a telepítő egy sor ellenőrzést, az AD-ra, DNS-re, vala- 
mint az aktuális felhasználóra vonatkozóan, továbbá megle- 
vő Exchange után is kutat. Csak akkor tudjuk a telepítést 
folytatni, ha minden rendben van. 

2. Miután útjára indítottuk a varázslót, a telepítő leállítja az 
összes olyan szolgáltatást, aminek köze van az Exchange- 
hez. Ilyen például az SMTP, az NNTP, a Windows Manage- 
ment, a Licence Logging, a Web kiszolgáló, az IISAdmin stb. 

3. Harmadik lépésben következik a szükséges könyvtárak és fáj- 
lok létrehozása, másolása a CD-ről, registrymódosítások és 
az új szolgáltatások telepítése. 

4. Végül a telepítő elindítja az összes Exchange 2000-rel össze- 
függő szolgáltatást. 

Ne türelmetlenkedjünk a telepítés során, egy fél órát is elmatathat 

a telepítéssel a kiszolgáló. Én nem csodálom, rengeteg dolga van. 

Aki nem hiszi járjon utána, ehhez ajánlom a [3] weboldalt, 11--97 

pontban van összeszedve mi minden történik a telepítés során. 


Dorner Csilla 
MCSE 


[1] http://technet.netacademia.net/2001/apr/ 
[21] http://technet.netacademia.net/2001/maj/ 
[3] http://www.microsoft.com/exchange/techinfo/reskit.htm 
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Aki kiváncsi ... 


.. az lehet, hogy tényleg nagyon hamar megöregszik, különö- 
sen akkor, ha követi a Microsoft egyik kutatója, Tom Barclay 
példáját. Ő arra gondolt, vajon megoldható-e egy terabájtnyi 
adat kezelése úgy, hogy azt a lassú kommunikációs vonalakon 
szörföző weblakók is könnyen használhassák? Tom költőivé mi- 
nősítette a kérdést, és ha nekem nem hiszik el, nézzék meg a 
saját szemükkel is az Egyesült Államok geológiai felmérésének 
(U.S. Geographical Survey - USGS) légifelvételeit! [1] 
Mostanában jómagam is foglalkozom (a kelleténél talán többet is) 
a digitális fényképezéssel, így hadd vegyek ebből, a cikk témájá- 
hoz meglehetősen közel álló világból egy analógiát, amelynél egy- 
szerűbben nem lehetne elmondani, mit csinált Tom az adatbázis 
tartalmát alkotó képekkel. Mi a teendő akkor, ha a látvány ,,kör- 
bevesz"? Sajnos ezen még a legjobb széles látószögű objektív sem 
segít, de körbefordulva készíthetünk több képet, amelyeket egy 
képfeldolgozó programmal össze tudunk illeszteni egyetlen képpé. 
"A lényeg nagyjából ennyi, de merüljünk kicsit a felszín alá. 

A Tom ötletéből kihajtó projekt eredeti célja a Windows 2000 
Server és az SOL Server megbízhatóságának és skálázhatóságá- 
nak bemutatása volt. Az elfogulatlannak éppen nem mondható 
állítás szerint a .NET rendszer és az XML bizonyult a legmegfe- 
lelőbbnek a terve kivitelezéséhez - ezt a tények is alátámaszt- 
ják. A webes TerraService-hez API-t is készítettek, amit felhasz- 
nálva a MapShots nevű cég már el is készítette a TerraFetch ne- 
vű ügyfélprogramot [2]. 

Következzenek most a platformfüggetlen részletek. Az USGS-től ka- 
pott felvételek nagysága egyenként 50-1500 MB, felbontásuk 1 mé- 
ter/pixel (ez az alapfelbontás). Első lépésben kiszámítják a képek 
pozícióját, majd - az átfedéseket is figyelembevéve - nagyobb ké- 
pekké állítják össze azokat, JPEG formátumra alakítják, és 200x200 
pixeles képelemekre szabdalják. Ezt követően elkészítik a kisebb fel- 
bontású, nagyobb területet átfogó képelemeket is, végül mindegyi- 
ket különféle azonosítókkal jelölik és tárolják az adatbázisban. 





5 A különféle képfelbontások elkészítése 


Mik ezek az azonosítók? A különféle képfelbontásokat (S: Scale) a 
webes felhasználás megköveteli. Egy adott felbontású képből 
rosszabbat az ábra szerint úgy készíthetünk, hogy minden négy pi- 
xelből csak egyet veszünk, az utolsó pixelnél (legrosszabb felbon- 
tás) pedig átlagolunk. Eszerint a felbontás a 2 hatványai szerint 
csökken: 1, 2, 4, 8, 16, 32, 64, 128 méter/pixel. Tovább nincs, hi- 
szen a 200x200 pixeles darabokból ennyi telik. A vastagon szedett 
felbontásokat az ábra jobb oldalán látható képek illusztrálják. A 
különböző forrásokból származó képek más-más típusúak lesznek 
az adatbáziban is (T: Theme). Nem kezelhetők egyformán például 
a légifelvételek, az űrfelvételek és a rajzok. Külön kategóriákat ké- 
peznek továbbá a gömb felszínét síkra leképező matematikai mód- 
szerek is. Mivel nem csak egy nagy felszeletelt képünk van, a kép- 
elemek egy további azonosítót kapnak a hovatartozásuk meghatá- 
rozására (Z: Zone). Ezenkívül tudnunk kell még a kép bal alsó sar- 
kának a teljes képhez viszonyított X és Y koordinátáit. Végül, a ha- 
todik adat mondja meg, hogy mely képelemek jeleníthetők meg 
ugyanazon a weboldalon (W). Ez a hat adat egyértelműen leír egy 
képelemet, és ha tudjuk mit keresünk, akár önállóan is összeállít- 
hatjuk a lekéréséhez szükséges URL-t, a [4] szerkezete szerint. 
Látszik, hogy az adatbázis felépítésénél a lehető legegyszerűbb 
megoldásra törekedtek. De akkor végülis mi ebben a nagy durra- 
nás? Egyrészt az adatmennyiség: az Interneten manapság elérhe- 
tő online adatbázisok méretének ez 10-100-szorosa. Másrészt a 
kivitelezés ideje: a TerraService webszolgáltatás kódjának velejét 
például Tom néhány nap alatt készítette el. Tom így anekdotázott 
erről: egy szakértőt küldtek hozzá, hogy felvilágosítsa a .NET-ről. 
Úgy érezte, az XML a leggyengébb pontja, ezért vett egy könyvet, 
hogy ne legyen teljesen lámer. A szakértő, mikor meglátta a 
könyvet az asztalán, fogta, és a kukába hajította, majd annyit 
tett hozzá, hogy erre nem lesz szükség, mert ami a könyben van, 
azt a .NET tudja, és elvégzi helyettük. A projekt mellesleg 1996 
végén indult, 1997 májusában mutatták be az első prototípust, a 
webhely pedig 1998 júniusában nyitotta meg kapuit. 
Mit sem ér azonban az olyan műszaki alkotás, ami nem érdekli a 
nagyközönséget, ezért szólni kell arról is, hogy a TerraService nem 
várt sikert aratott. Eddig körülbelül 50 millióan látogatták meg az 
oldalt, és más szervezetek is jelezték az igényüket arra, hogy a Ter- 
raService-t integrálják saját szolgáltatásaik közé. Ennek hatására 
csiszoltak a rendszerbeállításokon, így a Terra Service most napon- 
ta 300 ezer felhasználót képes kiszolgálni. Ez önmagában persze 
nem jelent komoly alkalmazást, de az már igen, hogy a farmerek 
információkat kapnak a talaj minőségéről, és így javíthatják a ter- 
melékenységüket, vagy a környezetvédők illegális szemétlerakó-he- 
lyeket kutathatnak fel egy számítógép segítségével stb. 
A nagyon kíváncsiak további részleteket találnak a [3] címen. 
Jó szórakozást! 

Zacco 


ea eel rag HAT 


[1]http://terraservice.net/ts4/about.asp?W-O 
[2]http://www.mapshots.com/downloads/TerraFetch.asp 
[3]http://terraserver.homeadvisor.msn.co/terra story images.asp 

[4]http: ://terraserver.microsoft.com/image. asp?T-185-108X-23428Y-1036882-108W-1 


working vith 


windows / 


2008. 03. 





TSDUBATA TAV / 


44 





45 


XMLgessünk 

XML sorozatunkban lépten-nyomon használtuk az XML sémát, láttuk, hogy rengeteg technológia épül rá. A 
következő részben megnézzük milyen sémák vannak a nagyvilágban, mire használható az XML séma, hogyan 
épül fel, hogyan kell írni és milyen segédeszközeink vannak a sémával kapcsolatos fejlesztésekhez. 


:NET Academia 

Valójában sokkal többet tudnak a delegate-ek mint amit ebben a számban felvázoltuk, például képesek sok 
metódusreferencia tárolására és automatikus meghívására is. Majd miután kiteljesítjük a korábban megkez- 
dett atomreaktoros példánkat rájövünk, hogy az ott végzett munkánk jelentős részét megspórolhatjuk, ha 
felhasználunk egy, a delegate-ekre épülő technológiát: a .NET beépített eseményeit. 


:NET 

Valójában sokkal többet tudnak a delegate-ek mint amit ebben a számban felvázoltuk, például képesek sok 
metódusreferencia tárolására és automatikus meghívására is. Majd miután kiteljesítjük a korábban megkez- 
dett atomreaktoros példánkat rájövünk, hogy az ott végzett munkánk jelentős részét megspórolhatjuk, ha 
felhasználunk egy, a delegate-ekre épülő technológiát: a .NET beépített eseményeit. 


Exchange 

Áprilisban először az exchange felügyeleti eszközeivel ismerkedünk, valamint megnézzük az Active Directory Users 
and Computers snap-inbe integrált Exchange varázslókat, majd sorra vesszük a felhasználók tulajdonságait. 
Ugyanebben a lapszámban megismerkedünk az Exchange Web Storage Sytem programozásával is! 


Research 

Egy átlagos kaliberű, komplett asztali számítógép ma megvásárolható mintegy 150 ezer Ft-ért. A legtöbb 
esetben - amikor egyáltalán be van kapcsolva - szövegszerkesztésre, játékra, internetezésre stb. használjuk, 
miközben a merevlemeznek a legjobb esetben is csak töredékét tudjuk értelmes adatokkal feltölteni. Bob 
Metcalf 9090-ra saccolja a parlagon hagyott hardvererőforrások arányát. Nyugodtan higgyük el, és nyugod- 
junk bele, hogy 135 ezer Ft-ot kidobtunk az ablakon. Bár arra senkit sem bíztatok, hogy várjon rá, a világ- 
háló horizontján már felbukkant a megoldást hozó világgép! 


Dinamikus DNS 2. rész: Secure DDNS 

Folytatjuk a Windows 2000 dinamikus DNS protokoll bemutatását: nem biztos hogy egészséges, ha bárki 
csak úgy frissítgetheti cégünk DNS zónájának tartalmát. Rend a lelke mindennek: ezúttal a biztonságos 
DDNS frissítés (Secure DDNS) kerül terítékre. 


Ingyenes hálózatfigyelő: Ethereal 

Magazinunkban hónapokon keresztül futott Network Monitor sorozatunk. A teljes funkcionalitású Network 
Monitor-hoz azonban (legalábbis hivatalosan) nem mindenki fér hozzá. Most bemutatunk egy ingyenes, tel- 
jeskörű hálózatanalizátor programot: az Ethereal bizonyos területeken még jobb is, mint a NetMon! 


Wörkiny VILER vihdoúuz 7 BUÚDZ. B§3. 


Következő számunk tartalmából 

















Jajjj ál: 


A távközlési piac liberalizálása és a mobiltelefóniában várható 


generációváltás érdekegyeztetési törekvéseiről tudósít ez a rovat. 


Külfödi hírek, kitekintés. 


Az Informatikai Kormánybiztosság 2001-— 2002-ben 
összesen 36 különféle programot koordinál. Az információs 
társadalom kiépítésének lépcsőfokai ezek. 


Az Inforum célja, hogy párbeszédet folytasson a szakma és a 
kormányzat között. Aktív szerepet vállalt a szerzői jogi, az 
egységes hírközlési és az elektronikus kereskedelmi törvény 
megalkotásában. 


A hónap vezető cikke új technológiákról, megoldásokról. 
Í 
! 


! Ebben a rovatban nem elsősorban a technológiára, hanem a 
megvalósult projektekre, az EU-kompatibilitás kérdéskörére, 
pályázatokra koncentrálunk. 


KeNPANNON SUPPORT 


RENDSZERHÁZ Kft. 


Komplett, korszerű kisvállalati megoldás! 


tzi Egorda Ad 1 KITZ Tate, 


Inter Pentium PIlII866 Mhz 
128MByte RAM (max. 1.5 GB) 
18.2 Gbyte SCSI HDD 

Adaptec 29160OLP SCSI 

FDD, CD 10/100 eth, 3 év garancia 


zta e eval (ad 


enge 


20 Gbyte HDD, CD, 10/100 ethernet 


ÁÖEKNKEZÉBBBB tan 


3 év garancia 


Tel.: 269-2233, 269-2797  Tel.: 382-0313, 382-0314 


Bp 1055. Honvéd u. 40. Fsz.8. F: 269-3058 


Inter Pentium C900 Mhz, 128MB RAM Í úr 


. Ms Windows 2000 Pro. Magyar, MET 


Az infopen.hu webmagazin és az infoBbYTE közös rovata, 
kifejezetten IT vezetők számára. A rovat egy aktív CIO-val 
készült átfogó interjúval indul, amelyet stratégiai jellegű 
technológiai áttekintések, szakcikkek követnek. A rovat 
hangsúlyos részei a vállalati IT megoldásokat bemutató 
esettanulmányok, de interjúk, konferenciatudósítások 
formájában a piac meghatározó megoldásszállító cégeinek üzleti 
és termékstratégiájának bemutatása is helyet kap. 


Tapasztalatok szerint három-négy évente változtatunk mi, 
informatikusok állást, szakmát vagy szakirányt, és ez a szám a 
jövő évtizedekben valószínűleg csökkenni fog. 


E rovárunkbun-olvasóiak nevében és helyett Novell szakértőket 
kérdez a szerző. 


Í N 


A NerAcutoria féle mélyvíz-tanfolyamokra iratkozhatnak be 
azon olvasóink, akik Dr. Watson nyomában járnak. 


Hades és szóban röviden, velősen. 


ez D 
JJ. 


Sokakat érdeklő CPU-újdonságok mélységei 
a fejlesztéshez közel álló szakértők tollából. 


Fe 
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Business 
Partner 


Microsoft 


CERTIFIED 


Bp 1119. Etele út 10. Fsz.1. F: 204-9292 


Infoopsr.hu 


jük! 


MS Small Business Server 2000 
Wgágve ZgONlNenőtendard Edition 
Exchange ki 


SOL Server 2000, ISA Server, 
Health Monitor, Managment Console, 
Windows FAX és Modem megosztási, 
szolgáltatás 


Válasszon! 
IBM NetVista A22p (PDD 
Inter Pentium IV 1,5Ghz 128MB RAM 
20 Gbyte HDD, CD, 10/100 eth 


Ms Windows 2000 Pro. Magyar, 
3 év garancia 


Cel.-os munkaállomásokkal: 1. 419. §. 00, 2 
pá munkaállomásokkal: 2. 49 0. 400,- 98 


zt tes munkaállomásokkal: f 649. 6§00,- x 
Páros munkaállomások 3.333.110,-t 


"A felüntetett ár tartalmazza: sze 

- 1db IBM xSeries 200Server; MS Small Business Server 200077 

- 5 felhasználó számára a szerver hozzáférést 

- 5db IBM munkaállomást (operációs rendszerrel, monitorral, billentyűzettel, egérrel) 

Igény esetén a rendszer megvásárlásához, lizing konstrukció kialakításában is segítünk! 

Január és február hónapban minden 1008 Ft feletti Microsoft és IBM terméket vásárlók között 

IBM WorPad-et sorsolunk ki! Áraink a 2596-os ÁFA-t nem tartalmazzák! Az árváltozás jogát fenntartjuk! 























Legyen Ön is BUG Hunter! A hivatalos egyenruhát képező speciális 
vadász trikó kiérdemléséhez mindössze annyit kell tennie, hogy az Ön 
által felfedezett BUG-okat levadássza! Hogy hol találhatja Őket? Ismeri 
a természetüket, természetesen bárhol a magazinban. A vadászat ered- 
ményéről értesítsen minket az e-mail címen, 
hogy mielőbb elküldhessük Önnek a hivatalos egyenruhát. 
Szerencsés vadászatot! 


